Prints a regular error instead of crashing.
The check is done in SILGen, because it's simple. We could also do it earlier, but I don't see a strong reason for this.
rdar://75950093
When a method is called with fewer than two parameter lists,
transform it into a fully-applied call by wrapping it in a
closure.
Eg,
Foo.bar => { self in { args... self.bar(args...) } }
foo.bar => { self in { args... self.bar(args...) } }(self)
super.bar => { args... in super.bar(args...) }
With this change, SILGen only ever sees fully-applied calls,
which will allow ripping out some code.
This new way of doing curry thunks fixes a long-standing bug
where unbound references to protocol methods did not work.
This is because such a reference must open the existential
*inside* the closure, after 'self' has been applied, whereas
the old SILGen implementation of curry thunks really wanted
the type of the method reference to match the opened type of
the method.
A follow-up cleanup will remove the SILGen curry thunk
implementation.
Fixes rdar://21289579 and https://bugs.swift.org/browse/SR-75.
Fixes crashes in 28437-swift-typechecker-validatedecl.swift (from previous commit)
and the compiler crasher 28861-gpdecl-getdepth-generictypeparamdecl-
invaliddepth-parameter-hasnt-been-validated.swift.
* Move most of the simd operators into an optional module
Adding simd to the stdlib caused some typechecker regressions. We can resolve them in the near-term by making the types universally available, but moving the arithmetic operators into a separate module that must be explicitly imported.
* Move two fuzzing tests back to fixed.
* Add SIMDOperators as a dependency for MediaPlayer.
* Move the .-prefixed operator declarations back into the stdlib.
Implements SE-0229.
Also updates simd module types in the Apple SDKs to use the new types, and updates a couple tests to work with the new types and protocols.
Thanks to @slavapestov for pointing this out! The optimization to avoid
looking through the members of a protocol that can’t possibly have any
associated types was for both deserialized protocols and imported
protocols, but I only supported the former in my previous change. Check
both cases and make the reasons much more obvious.
Also, that change resolved an existing compiler crasher as well.
A constraint like `Parameter == SomethingConcrete` means references to
`Parameter` in that context behave like `SomethingConcrete`, including for name
resolution. Handling the parameter as just a parameter type means that it won't
find any non-protocol nested types (i.e. things other than associated types and
protocol typealiases are invisible).
Fixes rdar://problem/42136457 and SR-8240.
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.
