These are all tests that would otherwise fail if the expression type
checker support for Swift 3 is removed.
I've moved some of the code from deleted Migrator tests into new
Constraints tests that verify that we do not support the constructs.
Rather than deferring to the heavyweight validateDeclForNameLookup()
to perform the “get overridden decls” operation, perform a much more
minimal validation that only looks for exact matches when the ‘override’
modifier is present.
The more-extensive checking (e.g., that one didn’t forget an override
modifier) is only performed as part of the “full” type checking of
a declaration, which will typically only be done within the same source
file as the declaration. The intent here is to reduce the amount of
work performed to check overrides cross-file, and limit the dependencies
of the “get overridden decls” operation.
The storage kind has been replaced with three separate "impl kinds",
one for each of the basic access kinds (read, write, and read/write).
This makes it far easier to mix-and-match implementations of different
accessors, as well as subtleties like implementing both a setter
and an independent read/write operation.
AccessStrategy has become a bit more explicit about how exactly the
access should be implemented. For example, the accessor-based kinds
now carry the exact accessor intended to be used. Also, I've shifted
responsibilities slightly between AccessStrategy and AccessSemantics
so that AccessSemantics::Ordinary can be used except in the sorts of
semantic-bypasses that accessor synthesis wants. This requires
knowing the correct DC of the access when computing the access strategy;
the upshot is that SILGenFunction now needs a DC.
Accessor synthesis has been reworked so that only the declarations are
built immediately; body synthesis can be safely delayed out of the main
decl-checking path. This caused a large number of ramifications,
especially for lazy properties, and greatly inflated the size of this
patch. That is... really regrettable. The impetus for changing this
was necessity: I needed to rework accessor synthesis to end its reliance
on distinctions like Stored vs. StoredWithTrivialAccessors, and those
fixes were exposing serious re-entrancy problems, and fixing that... well.
Breaking the fixes apart at this point would be a serious endeavor.
Implement TypeChecker::resolveInheritedProtocols() in terms of
"getInheritedType()" queries, instead.
[Sema] Put back resolveInheritedProtocols().
We're still depending on it to update state in some cases.
Since member lookup doesn't check requirements
it might sometimes return types which are not
visible in the current context e.g. typealias
defined in constrained extension, substitution
of which might produce error type for base, so
assignement should thead lightly and just fail
if it encounters such types.
Resolves: rdar://problem/39931339
Resolves: SR-5013
We could end up recursing through getTypeInContext() before we had time to
diagnose the recursion, so be *certain* that we can't recurse here to fix
a few crashes.
Crashers 28598 and 28778 are creating invalid validation requests for the ITC
by using unqualified lookup to get the validator to jump inside of a
transitively invalid DeclContext.
Just don't load these members.
While trying to resolve nested type component with type parameter
as a parent, try to resolve it as dependent member directly but
if that fails go through longer resolution path which is required
in case member type is accessed using `typealias`.
Resolves: rdar://problem/39253925
The amp_prefix token is currently tolerated in any unary expression
context and then diagnosed later by Sema. This patch changes parsing to
only accept tok::amp_prefix in its allowed position: parameter lists.
This also fixes two "compiler crasher" tests.
With the exception of “has type variable”, which affects the arena used
for storage of a BoundNameAliasType, only propagate recursive properties
from the underlying type to a BoundNameAliasType, because the other
properties (e.g., “has archetype” or “has type parameter”) pulled from
syntactic sugar don’t apply.
Currently, when we reference a (non-generic) typealias within a
generic context, we would completely lose type sugar for the
typealias, replacing it with the underlying type. Instead, use
BoundNameAliasType for this purpose, which allows us to maintain all
of the type sugar as well as storing complete substitutions for later
use.
The DeclChecker had three possible states:
- IsFirstPass true, IsSecondPass false. This is the 'first pass' for
declarations that appear at the top-level, or are nested inside
top-level types.
- IsFirstPass false, IsSecondPass true. This is the 'second pass' for
declarations that appear at the top-level, or are nested inside
top-level types.
- IsFirstPass false, IsSecondPass false. This was used for (some)
local declarations.
This is unnecessarily confusing. We can eliminate the third state
by calling typeCheckDecl() twice in a few places. This allows
IsSecondPass to be removed entirely since it's now always equal to
!IsFirstPass.
This is useful for explicit casts and type expressions, where
type loc and expression types might be different, and allows
constraint solver to avoid setting opened types to expressions
which resolves multiple crashes.
When bindings are picked for particular type variable, right-hand
side of the binding might be another type variable wrapped into optional
type, when trying to determine if both sides of the binding have the
same l-valueness it's imperative to look throught optional type of the
right-hand side. Otherwise new binding might be effectively unsolvable.
Resolves: rdar://problem/37291371
A type Foo<...>.Bar may only exist conditionally (i.e. constraints on the
generic parameters of Foo), in which case those conditional requirements
should be implied when Foo<...>.Bar is mentioned.
Fixes SR-6850.
There was a path through associated type inference where we would end
up recording a type witness that contained an error, but for which we
had not reported that error, which would lead to downstream
crashes. Make sure that we reject such inferences.
And because it triggers once we fix this issue... make sure break
recursion when trying to resolve type witnesses lazily.
Fixes the crash in SR-6609 / rdar://problem/36038033, but we're still
failing to infer in those cases.
Redeclaration checking was validating all declarations with the same
base name as the given declaration (and in the same general nominal
type), even when it was trivial to determine that the declarations
could not be conflicting. Separate out the easy structural checks
(based on kind, full name, instance vs. non-instance member, etc.) and
perform those first, before validation.
Fixes SR-6558, a case where redeclaration checking caused some
unnecessary recursion in the type checker.
For Swift 3 / 4:
Deprecate the spelling "ImplicitlyUnwrappedOptional", emitting a warning
and suggesting "!" in places where they are allowed according to
SE-0054.
In places where SE-0054 disallowed IUOs but we continued to accept them
in previous compilers, emit a warning suggesting "Optional" or "?" as
an alternative depending on context and treat the IUO as an Optional,
noting this in the diagnostic.
For Swift 5:
Treat "ImplicitlyUnwrappedOptional" as an error, suggesting
"!" in places where they are allowed by SE-0054.
In places where SE-0054 disallowed IUOs, emit an error suggestion
"Optional" or "?" as an alternative depending on context.
We can't construct a nominal type with an ErrorType as a
parent, so in the bad circular case, return a Type() instead
to bail out of transform() altogether.
This commit also adds ArrayExpr and DictionaryExpr to the libSyntax nodes
family. Also, it refactors the original parser code for these two
expressions to better fit to the design of SyntaxParsingContext.
This commit has also fixed two crashers.
Previously, we were inferring requirements from types within the definitions
of protocols, e.g., given something like:
protocol P {
associatedtype A: Collection
associatedtype B where A.Element == Set<B>
}
we would infer that B: Hashable. The code for doing this was actually
incorrect due to its mis-use of requirement sources, causing a few
crashers. Plus, it's not a good idea in general because it hides the
actual requirements on B. Stop doing this.
Also stop trying to infer requirements from conditional
requirements---those have already been canonicalized and minimized, so
there's nothing to infer from.
If we encounter a superclass or concrete source within a conformance
access path, use the stored conformance to terminate the path. Fixes a
compiler crasher.
