adding full spaceengine changes
using clang-format
adding argument name size comparison
adding space engine changes
adding full spaceengine changes
using clang-format
adding argument printing to interleave function
updating tests for new print formatting
removing extra checks from constructor subspace checking
adding alternate path if the argument and space lenght are the same
clang format
adding FIXME for code performance
adding fixme for showing constructor
switching direction of beginningparenthesis
There is a small chance that codegen and everything works fine, but the
generated code is wrong because of mismatched expectations on two sides,
so we have some tests to catch that.
Also fixes rdar://problem/53312914.
The fact that ParenType is being used to distinguish the two cases makes me
uncomfortable but I don't have better ideas.
Related:
- Fixed a bug in pattern projection which I encountered once I fixed SR-11160.
This is the 3 line change around conArgSpaces.
- Opened SR-11212 for ill-typed patterns that are permitted to compile.
Unrelated cleanup:
- Removed a redundant switch case in 'isSubspace'.
- Added names for referenced papers for faster lookup.
Expression patterns (and cast patterns) don't actually contribute to
the exhaustivity of a switch statement---if you're matching against a
String, matching "abc" doesn't meaningfully reduce the full space of
the values you have to match. This was already handled, but didn't do
the right thing in a particular case involving a tuple payload in an
enum after the Space Engine (exhaustivity checker) optimizations that
went out in Swift 5.
https://bugs.swift.org/browse/SR-10301
This is a new feature of Swift 5 mode, so it deserves at least a
little bit of explanation right in the diagnostic. If you have an
otherwise-fully-covered switch but can't assume the enum is frozen,
you'll now get this message:
switch covers known cases, but 'MusicGenre' may have additional
unknown values
Furthermore, if the enum comes from a system header, it looks like
this:
switch covers known cases, but 'NSMusicGenre' may have additional
unknown values, possibly added in future versions
...to further suggest the idea that even though your switch is covered
/now/, it might not handle everything in the /future/. This extra bit
is limited to system headers to avoid showing up on C enums defined in
your own project, for which it sounds silly. (The main message is
still valid though, since you can cram whatever you want into a C
enum, and people use this pattern to implement "private cases".)
rdar://problem/39367045
In light of the invocation limits placed on space subtraction, this grossly incorrect check is being dropped.
Resolves a source of miscompiles in mostly machine-generated code
including SR-6652 and SR-6316.
Fixes SR-8933.
Swift's uninhabited checking is conservative. An enum might not be found to be uninhabited, but all of its cases might. In that case, the switch can be empty even though the type isn't known to be uninhabited.
Fix an assertion that assumed there would always be at least one case for types that aren't known to be uninhabited.
Without this, the compiler ended up complaining about missing cases
that can't actually occur, like `Optional<Never>.some(_)`. This was a
regression from Swift 4.1.
https://bugs.swift.org/browse/SR-8125
A corner-case left over from an earlier fix that made exhaustiveness
checker aware of irrefutable coercions. If the coercion occured as part
of a sub-pattern, that pattern would be projected with the wrong type
and would fail the intersection test. Project the pattern with the type
of the scrutinee instead.
Projection assumed if it ever hit a case where an argument pattern
contained extra parentheses that the user was trying to create
a var pattern to bind the entire argument tuple.
enum Foo {
case bar(Int, String, Float)
}
switch fooVal {
case bar(let x): ...
}
This breaks in the presence of tuple patterns with extra parentheses.
Treat these patterns explicitly when projecting them.
Note that I said "warnings"; we're going to be more cautious about
rollout and just make this a warning in Swift 5 mode, with /no/
diagnostics in Swift 3 and 4. Users are still free to use `@unknown
default` in these modes, and they'll get a fatal run-time error if
they don't and an unexpected case actually shows up.
rdar://problem/29324688
At one point compiler wouldn't let you use them in matches, so people have
had to use catch-all cases instead. SILGen already handles this because of
@_downgrade_exhaustivity_check, as well as non-exhaustive enums in
Swift 4 mode.
rdar://problem/33246586
- Combine the common logic for editor mode and non-editor mode.
- Do a better job minimizing fix-its.
- If '@unknown' is the only missing case, put `fatalError()` in the
Xcode placeholder, since that's what the compiler would have done.
That is, when matching non-frozen enums at non-top-level positions:
switch (nonFrozenEnum1, nonFrozenEnum2) {
case (.singleKnownCase1, .singleKnownCase2): ...
unknown: ...
}
...it's sufficient to use '@unknown' to match
(.singleKnownCase1, .someFutureCase2)
(.someFutureCase1, .singleKnownCase2)
(.someFutureCase1, .someFutureCase2)
The other half of '@unknown' in Sema. Again, the diagnostics here
could be improved; rather than a generic "switch must be exhaustive",
it could say something about unknown case handling known cases.
One interesting detail here: '@unknown' is only supposed to match
/fully/ missing cases. If a case is /partly/ accounted for, not
handling the rest is still an error, even if an unknown case is
present.
This only works with switches over single enum values, not values that
contain an enum with unknown cases. That's coming in a later commit.
(It was easier to get this part working first.)
The first half of Sema support for '@unknown'. The other part is
handling when the user /does/ write '@unknown', which results in
/other/ things being downgraded to warnings.
The diagnostics here are still pretty minimal; they should explain
what's going on with '@unknown' to someone who hasn't read the Swift 5
release notes.
Warn in Swift 4 mode and error in Swift 5 mode when switching on a
non-frozen enum without providing a default case.
Note that this is a preliminary implementation, in order to test the
rest of the feature.
This presents a regression in diagnostic quality that is definitely
worth it not to lie to SILGen about whether a switch is covered or not.
At the same time, disable SIL’s unreachable diagnostic for ‘default’
clauses which would previously cause a warning to be emitted if the
default was proven to be unreachable. This analysis is incomplete
anyways and can be done by Sema in the future if we desire.
The Space Engine includes a heuristic that attempted a combinatorics-
based check to see if a pattern covered an insufficient amount of cases.
In straight-line switches this avoided computing a subspace match that
would have been quite expensive computationally. However, when
expressive patterns (like tuple patterns) are used, it can fool the
check because the covered space is much larger than the actual size of
the space due to pattern overlap that counting like this simply can't detect.
Instead, just do the right thing and perform a space subtraction after
the existing preconditions for the heuristic are satisfied.
Resolves SR-6316
Integer and Floating literals are aware of their negation but
do not store the sign in the text of the value. Retrieve the
sign bit and properly interpolate the text of the literal value
with it to distinguish negative and positive literals.
Cuts off a crash in SILGen for switches over uninhabited types.
We can take this a step further and extend the definition of
"uninhabited" to product types with uninhabited components.
<rdar://32480026>
This is a particularly tricky tradeoff to have to make here. On the one
hand, we want diagnostics about incomplete patterns to provide as much
information as possible. On the other, pattern matrices grow
quasi-factorially in the size of the argument. That is, an enum with 10
cases that is switched on as a 2-tuple/argument list creates a total
subspace covering of size 100. For sufficiently large inputs, this can
DOS the Swift compiler.
It is simply not useful to present more than about 100 notes to the
user, nor is it useful to waste an enormous amount of time trying to
compute these subspaces for the limited information the diagnostic will
provide. Instead, short circuit if the size of the enum is above some
arbitrary threshold (currently 128) and just offer to add a 'default'.
Notably, this change is not *technically* source compatible in that it
ignores the new '@_downgrade_exhaustivity_check'. However to hit up
against this heuristic would require the user to be switching over four
DispatchTimeIntervals in a quadruple or using an equivalently-sized
enormous enum case. At which point we're hitting on the very reason
this heuristic exists.
There are definitely other, more informative, paths that we can take
here. GHC, for example, seems to run a highly limited form of space
subtraction when the input space is too large, and simply reports the
top 3 missing cases along with some ellipses. For now, I just want to
cut off this hang in the compiler.
To further cut down on the number of cases present,
add a filter that catches if the flattening algorithm ever hands us back
a pattern matrix that contains duplicate entries. Note that this does
not, by definition, affect pattern completeness.
