[SR-8377] Strange implicit optional conversions in generic code with key paths #50904
Labels
bug
A deviation from expected or documented behavior. Also: expected but undesirable behavior.
compiler
The Swift compiler in itself
type checker
Area → compiler: Semantic analysis
Attachment: Download
Environment
swift master 665bcb9
Additional Detail from JIRA
md5: 2dd2f2f44b786c535b63b12bee71bf8d
Issue Description:
I've stumbled upon this issue intermittently on the latest master branch. It was an issue when working on the code forked of last weeks master. When I wanted to file this bug yesterday, I wasn't able to reproduce on Tuesday's master. I was about to commit a simplified code and remove the workaround for the issue today, but I see the problem again with Wednesday's master.
I'm about to leave for vacation, so I don't have time to reduce it further. All I have is this slightly confusing println debugging patch against master and a test case invocation that demonstrates the issue. I hope you'll be able to reproduce it.
The issue manifests in the code of Swift Benchmark Suite, in the
DriverUtils.swift
. That code is using failable initializers for numeric types to do the type checking in thechecked
function. There are two generic functions involved and the type inference has to go through KeyPaths. The parser for--sample-time
is a bit more complex, because it has to only accept finite Double values (excludingNaN
and±Infinity
), this is done using the optionalfilter
pattern. So the closure body is a chain of failableinit
andflatmap
(the simpler cases with just the failableinit
, used for other attributes don't have this issue). It is further complicated by the fact that the type of the resulting value (which is stored into theresult
) is also optional. I'm not sure which part of this rather complex setup is causing the issue, just pointing out to potential leads…I'm compiling the benchmarks with
Then there's one lit test (prefixed
NANVALUE
), that checks the error handling of parsing the arguments forBenchmark_O
does the type conversion correctly. With the issue present, the test will take very long to fail, because it devolves into running the whole pre-commit test suite instead of failing quickly with the expected error message. Here's a modified invocation that will always fail quickly:The first invocation with
NaN
should fail the same way as the second, with the error message.The issue arises when the parser is specified with untyped inline closure. Adding explicit type information to the closure or converting it to nested function works around the issue. But as the debug messages added to
checked
(after converting the parser closure to escaping, required by the need to pass it intoString
) demonstrate, the type information inside thechecked
function remains the same for the inferred case and explicitly typed case.First the expected behavior with explicitly typed parser (inline or nested functions both work), including
--num-iters : UInt
for comparison:Note: error is printed to stderr, which is why it appears first, even though its later in the code.
The issue with inline type-inferred parser:
It looks to me like there is some funky implicit conversion going on somewhere? Or something is eliminating the
flatMap
call?The text was updated successfully, but these errors were encountered: