Absence of synthetic generic environment should not affect
serialization of the required substitutions because they can
come from outer requirement context for static members.
Resolves: rdar://problem/36497404
StdlibUnittest uses gyb to avoid duplicating many source-context
arguments. However, this means that any test that wishes to add new
expect helpers has to also be gybbed. Given that this structure hasn't
changed in years, and we should have a real language support
eventually, de-gyb it.
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.
If there was any requirements in the @objc protocol, the user got an error in
some form (a complaint about those requirements), but giving the direct error is
better, and handles @objc protocol with no requirements.
Also, fix a hole in that existing @objc method check: in `class Outer<T> { class
Inner {} }`, Inner should be considered generic, but the loop that was checking
for this didn't consider it.
Fixes https://bugs.swift.org/browse/SR-7370 and rdar://problem/39239512.
Since this code was first written, we've added more language features that introduce the opportunity for a materializeForSet protocol witness to have an incompatible polymorphic convention with its concrete implementation:
- In a conditional conformance, if a witness comes from a constrained extension with additional protocol requirements, then the witness will require those conformances as additional polymorphic arguments, making its materializeForSet uncallable from code using the protocol witness.
- Given a subscript requirement, the witness may be a generic subscript with a more general signature than the witness, making the generic arguments to the concrete materializeForSet callback incompatible with those expected for the witness.
Longer term, representing materializeForSet patterns using accessor coroutines should obviate the need for this hack. For now, it's necessary for correctness, addressing rdar://problem/35760754.
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
Builds on 36eae9d4f6 to emit a message instead of just trapping
when a switch over a non-frozen enum ends up not matching anything.
If the enum is known to be an @objc enum, the message is
unexpected enum case 'MyEnum(rawValue: -42)'
and if it's anything else (a Swift enum, a tuple containing enums,
whatever), it's a more opaque
unexpected enum case while switching on value of type 'MyEnum'
The reason for this is to avoid calling String(describing:) or
String(reflecting:) an arbitrary value when the enum might conform to
CustomStringConvertible and therefore /itself/ have a switch that's
going to fall off the end. By handling plain @objc enums (using a
bitcast), we've at least covered the 90% case.
rdar://problem/37728359
Usually this happens directly, through some use of the class and its
conformance. However, if a conformance is /only/ used to satisfy an
associated type, we seem to bypass the step that actually infers
selector names for accessors, even though we do it successfully for
methods. Fix this by making sure the accessor decls are validated when
a property is, something that normal uses of a property probably have
to do anyway.
Also, simplify inferObjCName by assuming/asserting that it is only
used on things that are already marked @objc.
https://bugs.swift.org/browse/SR-6944
We were hitting an unreachable in visitDynamicMemberExpr in ExprRewriter when
re-typechecking during a salvage. Check for these earlier (in CSGen) and update
SanitizeExpr to handle them.
Resolves rdar://problem/39055736
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.
Don't attempt to store literal bindings directly to `PotentialBindings`
since they might get superseded by non-literal bindings deduced from
other constraints, also don't attempt to check literal protocol conformance
on type variables or member types since such types would always end-up
returning trivial conformance which results in removal of viable literal types.
Resolves: rdar://problem/38535743
`PreCheckExpression` should only walk into associated closure if
it's a single statement, and should avoid list itself since it should
already be properly type-checked by `typeCheckDecl`.
Resolves: rdar://problem/34852808
Switch StringObject and StringGuts from opaquely storing tagged cocoa
strings into storing small strings. Plumb small string support
throughout the standard library's routines.
Streamline internal String creation. Previously, everything funneled
into a single generic function, however, every single call of the
generic funnel had relevant specific information that could be used
for a more efficient algorithm.
In preparation for efficiently forming small strings, refactor this
logic into a handful of more specialized subroutines to preserve more
specific information from the callers.
This fixes two easy cases where we would go exponential in type
checking tuple literals.
Instead of generating a conversion to a single type variable (which
results in one large constraint system), we generate a conversion ot
the same type that appears in the initializer expression (which for
tuples is a tuple type, which naturally splits the constraint system).
I experimented with trying to generalize this further, but ran into
problems getting it working, so for now this will have to do.
Fixes rdar://problem/20233198.
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.
