Instead of constructing calls to
ExpressibleByNilLiteral.init(nilLiteral: ()) in CSApply.cpp, just
annotate NilLiteralExpr with the selected construtor and do the actual
construction during SILGen.
For context, StringLiteralExpr already behaves this way.
* Make sure that base and unwrapped types aren't null
* Don't allocate `ForceOptional` fix if nothing has been unwrapped
in `simplifyApplicableFnConstraint`
* Add sugar reconstitution support to `FailureDiagnostic::resolveType`
* Format diagnostics a bit better
Currently that has been limited only to expressions which aren't
flagged as `TCC_ForceRecheck`, but it should be extended to all
sub-expressions, otherwise we might produce invalid diagnostics
in `PreCheckExpression`.
The diagnostics for `variable_never_mutated` always suggests
changing `var` to `let`, which is misleading in case of
for-each loops where explicitly immutable context applies.
This patch adds some variety to the message to make it appropriate.
Resolves: SR-9732
NSObject.hashValue used to be declared `@objc open` by historical accident. This has been corrected to `@nonobjc public` in Swift 5’s SDK overlays, to catch accidental overrides. (These never did work correctly, and shouldn’t have been allowed.)
Help migration by adding a dedicated error message for NSObject.hashValue overrides, with a nice fix-it.
rdar://problem/45674813
Instead of storing information about expression depths in the
solver state (which gets recomputed for salvage) let's track
it directly in constraint system, which also gives solver
access to it when needed e.g. for fixes.
For lazy vars, we need to make public the top-level entry point, and the fact
that the lazy storage contributes to the layout of a type (if it’s fixed
layout, or if the type is not resilient.) We also shouldn’t ever print `lazy`
in a parseable interface.
Since we need to parse these identifiers, give them a new name,
`$__lazy_storage_$_{propname}`, which is parseable only in parseable interfaces
so it doesn’t conflict with other properties.
Currently if member has been found through same-type constraint
it would only be properly handled when it comes from a class type,
because that's the only time when base type gets replaced with
"concrete" type from equivalence class, but nested types could also
come from structs, enums and sometimes protocols (e.g. typealias)
which `resolveDependentMemberType` has to handle.
Resolves: rdar://problem/47334176
The problem Assume 'A' and 'B' are enums with cases .a1, .a2, etc. and
.b1, .b2, etc. If we try to typecheck this switch:
switch (a, b) {
case (.a1, .b1),
(.a1, .b2):
break
...
The compiler is going to try to perform the following series of
operations:
> var s = (A, B)
> s -= (.a1, .b1)
((A - .a1, B) | (A, B - .b1))
> s -= (.a1, .b2)
(((A - .a1, B) | (A - .a1, B - .b2)) |
((A - .a1, B - .b1) | (A, B - .b1 - .b2)))
...
As you can see, the disjunction representing the uncovered space is
growing exponentially. Eventually some of these will start
disappearing (for instance, if B only has .b1 and .b2, that last term
can go away), and if the switch is exhaustive they can /all/ start
disappearing. But several of them are also redundant: the second and
third cases are fully covered by the first.
I exaggerated a little: the compiler is already smart enough to know
that the second case is redundant with the first, because it already
knows that (.a1, .b2) isn't a subset of (A - .a1, B). However, the
third and fourth cases are generated separately from the first two,
and so nothing ever checks that the third case is also redundant.
This patch changes the logic for subtracting from a disjunction so
that
1. any resulting disjunctions are flattened, and
2. any later terms that are subspaces of earlier terms are dropped
This is a quadratic algorithm in the worst case (compare every space
against every earlier space), but because it saves us from exponential
growth (or at least brings down the exponent) it's worth it. For the
test case now committed in the repository, we went from 40 seconds
(using -switch-checking-invocation-threshold=20000000 to avoid cutting
off early) to 0.2 seconds.
I'll admit I was only timing this one input, and it's possible that
other complex switches will not see the same benefit, or may even see
a slowdown. But I do think this kind of switch is common in both
hand-written and auto-generated code, and therefore this is likely to
be a benefit in many places.
rdar://problem/47365349
Adds proper diagnostics when using unresolved labels on break statements inside loops. In case of simple typos, also provides suggestions and fixits. Right now, the misleading "error: 'break' is only allowed inside a loop, if, do, or switch" is emitted in 4.2 and master.
Resolves SR-9677.
The intention here is to be able to detect warnings earlier and
move some of the logic from CSApply and MiscDiagnostics to solver.
Warning fixes still lead to solution being applied to AST.
