`SK_Fix` was used to indicate that solver has encountered a hole
along the current path but since there is `SK_Hole` now, increasing
`SK_Fix` no longer makes sense.
It might be either impossible to infer the base because there is
no contextual information e.g. `_ = .foo` or there is something
else wrong in the expression which disconnects member reference
from its context.
This warning is produced if you annotate an enum with `@frozen` but
build without library evolution enabled. The problem is that if you
only build with library evolution enabled for release builds, this
leaves you with a warning for all debug builds. The downside of this
change is that if you never build with library evolution, you may have
this unnecessary annotation without noticing.
all cases of missing generic parameters.
In `ComponentStep::take` when there are no bindings or disjunctions, use hole
propagation to default remaining free type variables that aren't for generic
parameters and continue solving. Rather than using a defaultable constraint for
holes, assign a fixed type directly when we have no bindings to try.
In order to remove the enum raw value check request in validateDecl,
IRGen must now tolerate recieving an invalid raw value expression.
Switch the assert to instead check for this condition and emit an
invalid negative discriminator.
Argument-to-Parameter mismatch handles conformance failures
related to arguments, so the logic in `MissingConformanceFailure`
which wasn't entirely correct is now completely obsolete.
Resolves: rdar://problem/56234611
In preparation for checkEnumRawValues being turned into a request, move the common diagnostics to the decl checker so they're always emitted at the right time.
@objc enums have special requirements on the raw type, which were
enforced as part of checking the raw type of the enum. Rework the
checking here so that the additional constraints are part of resolving
whether the enum is exposed to Objective-C. This keeps raw-type
computation more independent and “lower-level” than @objc computation.
Once reworked, eliminate the “CIntegerTypes” cache from TypeChecker:
it probably doesn't matter, and the caching should be performed by the
request-evaluator rather than the type checker.
In Swift 4, constructors had the same name as properties,
methods and enum cases named `init`. This meant that you
could use constructor syntax to call such a member, which
caused some confusing behavior.
Recently I added a special declname for `init` so that
constructors have unique names distinct from any name you
can spell, and "foo.init" syntax would look for a member
with the special name rather than one named `init`.
Unfortunately people actually had code where they defined
members named `init` and then use them via normal member
lookup syntax, like this:
enum E {
case `init`
}
let e: E = E.init
So to maintain backward compatibility, hack member lookup
to also find members named `init` when looking up the special
declname for constructors.
The workaround is only enabled in Swift 4 and 4.2 mode;
in Swift 5 mode you are expected to write "foo.`init`" to access
non-constructor members named `init`.
Fixes <rdar://problem/38682258>.
This fixes a 4.2 regression where enums and subscripts could not
contain single-argument function types with an 'inout' parameter,
because we erroneously diagnosed the 'inout' as if it appeared
at the top level of the enum case or subscript index type.
Fixes <https://bugs.swift.org/browse/SR-7890>.
Continue to emit notes for the candidates, but use different text.
Note that we can emit a typo correction fix-it even if there are
multiple candidates with the same name.
Also, disable typo correction in the migrator, since the operation
is quite expensive, the notes are never presented to the user, and
the fix-its can interfere with the migrator's own edits.
Our general guidance is that fix-its should be added on the main
diagnostic only when the fix-it is highly likely to be correct.
The exact threshold is debateable. Typo correction is certainly
capable of making mistakes, but most of its edits are right, and
when it's wrong it's usually obviously wrong. On balance, I think
this is the right thing to do. For what it's worth, it's also
what we do in Clang.
I tried doing this directly from typeCheckDecl(), but it breaks
associated type inference. We can figure this out later when
declaration checking becomes lazier and more incremental.
Note that typo correction does not force witnesses of
synthesized conformances. This means that a typo correction
from a top-level form will no longer pick up synthesized
witnesses, and will find the protocol requirement instead.
To give a test the same behavior as before, I put the
expression in a function body instead of a top-level form.
Note that we already had the same behavior with typo
correction from pattern binding initializers and other
contexts that are type checked before conformances.
(currently spelled with an underscore to indicate its WIP state)
Later commits will handle imported enums correctly and implement the
checks for switch cases.
A given Objective-C error enum, which is effectively an NS_ENUM that
specifies its corresponding error domain, will now be mapped to an
ErrorProtocol-conforming struct that wraps an NSError, much like
NSCocoaError does. The actual enum is mapped to a nested "Code"
enum. For example, CoreLocation's CLError becomes:
struct CLError : ErrorProtocol {
let _nsError: NSError
// ...
@objc enum Code : Int {
case ...
}
}
This implements bullet (2) in the proposed solution of SE-0112, so
that Cocoa error types are mapped into structures that maintain the
underlying NSError to allow more information to be extracted from it.
along with recent policy changes:
- For expression types that are not specifically handled, make sure to
produce a general "unused value" warning, catching a bunch of unused
values in the testsuite.
- For unused operator results, diagnose them as uses of the operator
instead of "calls".
- For calls, mutter the type of the result for greater specificity.
- For initializers, mutter the type of the initialized value.
- Look through OpenExistentialExpr's so we can handle protocol member
references propertly.
- Look through several other expressions so we handle @discardableResult
better.
