This was done back in Swift 3.0.1 or 3.0.2. Let's finally make them
errors in Swift 4!
I also fixed up a number of '%error' entries in diagnostics that can
actually happen in invalid code. These are the ones that were already
present in the warnings.
The type of non-strong properties is wrapped in a ReferenceStorageType,
which does not conform to Codable. This needs to be unwrapped so the
inner reference type can be considered for Codable conformance.
Validation for typealiases in protocols is... odd. It needs to avoid
depending on the whole protocol being validated, so it does an initial
validation that can leave nested types of Self (and other associated
types) somewhat unresolved. In these cases, do something icky but
partially effective: when we resolve the protocol, go back and clean
up the types of these typealiases.
A better solution would allow us to use the types of these typealiases
within the Generic Signature Builder without recording them in the AST
as "the interface type", so there's no way unresolved nested types
could be found (and, therefore, nothing to "fix up" later). Howwever,
that's a more significant undertaking.
Fixes rdar://problem/32287795.
When an unqualified reference is overloaded, we would walk
the list of overload candidates and check if they are all
member accesses. If they are, we would form an
UnresolvedMemberRefExpr with the right base. Otherwise,
we would form an UnresolvedDeclRefExpr.
Now, consider forming an UnresolvedMemberRefExpr even if
some of the members are types. This forces all nested
type lookups to go through getTypeOfMemberReference(),
not getTypeOfReference().
As a result, we no longer pass nested types to the
resolveTypeInContext() function from expression checking.
This will allow resolveTypeInContext() to take the base
declaration on which the nested type was found as a
parameter, instead of walking parent DeclContexts to
try to guess what the right base was.
resolveGenericTypeParamType(), resolveTypeOfDecl() and
resolveTypeOfContext() would all take the type of a
declaration, and optionally map it into context.
Replace them with a mapTypeIntoContext() that takes a
type and either returns it verbatim or maps it into
context.
Keep track of the protocol conformances required to form a particular
solution. At the point where we apply a solution, mark each of those
conformances as "used" so we're sure they are complete for later
phases (SILGen, SIL optimizer, IRGen). This general mechanism makes
sure we don't miss any cases in CSApply, such as the multi-case
illustrated in the new test where CSApply doesn't form any AST notes
describing the type erasure in a function conversion, so it otherwise
wouldn't see the conformance to mark it "used".
Pavel went most of the way down this path to track conformances last
month for unrelated reasons (that didn't really pan out). Resurrect
his work to track conformances, but only use them to mark as "used".
Fixes rdar://problem/32111710.
Track outcomes of `conformsToProtocol` calls in `simplifyConformanceConstraints`
to be able to validate conformances when solution is formed to avoid returning
solutions with nominal types with invalid conformances to protocols.
Push the getName method from ValueDecl down to only those types that are
guaranteed to have a name that is backed by an identifier and that will
not be special.
Between syntactic restrictions and later checks for spurious '&'
expressions, we don't need to check for '&' expressions when coercing
to an rvalue. Plus, 'inout' doesn't imply 'not lvalue', so we'd never
get here.
ConstraintSolver::coerceToRValue() missed a bunch of cases where we
should be dealing with lvalues, e.g., tuples, "try" expressions, and
so on. Extend TypeChecker::coerceToRValue() to deal with the
expression type side-tables and ConstraintSolver::coerceToRValue() to
it.
Fixes rdar://problem/32700180, a crash-on-valid.
Codable failures produced diagnostics and notes explaining what failed
during decode. These diagnostics were being output as they were
generated, which was suboptimal because it meant that NOTEs could be
produced before the error they were related to.
This was bad for consumers like Xcode, which associate NOTEs with the
last error or warning diagnostic.
This collates these notes using a diagnostic transaction and only
outputs the errors if something goes wrong.
In anticipation of removing this bit, move it from the
recursive type property into TupleType - its only real
user. This necessitates uglifying a bit of logic in the
short term that used to speak broadly of materializability
to instead speak about LValues and Tuples of InOut values
independently.
When evaluating if a call of a local function requires substitutions,
we checked if the immediate function being referenced captured
generic parameters, without checking if it transitively captured
generic parameters via other local functions it references.
Also, when calling accessors, we did not perform this check at all.
Fix both ordinary function calls and accessor calls to drop the
substitutions only if the *lowered* local captures say it is safe.
Finally, fix Sema to not consider substitutions in local function
references as generic parameter captures, since we now correctly
calculate the transitive closure of all captures.
Fixes <rdar://problem/32761305> and related issues.
When re-typechecking an expression during diagnostics, we begin by
erasing all the types in the expression. However, any expressions
created as part of applying the solution will remain.
CSGen was doing the wrong thing when it encountered EnumIsCaseExpr,
which can only appear in already-type checked ASTs.
Returning expr->getType() is not correct, because the type is not
yet set; returning a null type is intended to signal that a
diagnostic was already emitted, which causes Sema to stop
type checking.
The end result is that certain combinations of invalid code with
an 'is' cast nested inside would crash either the AST verifier
(with asserts on) or in SILGen (with asserts off), because we
would stop trying to diagnose the issue prematurely, and possibly
not emit a diagnostic at all.
Fixes <https://bugs.swift.org/browse/SR-5050> and
<rdar://problem/32487948>.
Generates a warning for any expression that takes longer than <limit>
milliseconds to type check. This compliments the existing
-warn-long-function-body=<limit> option.
When applying a solution to an ApplyExpr, we have to coerce the
argument to the input type of the function. This is because the
solution succeeds if the argument is convertible to the
function's input, not just if they are equal.
We were forgetting to do that for the special case of a type(of:),
which has its own semantics.
Fixes <rdar://problem/32435723> and
<https://bugs.swift.org/browse/SR-5168>.
Instead of doing that, suggest removing 'var' altogether because
'let' cannot be used directly in an implicitly immutable context.
Resolves: rdar://problem/32390726
* The SILBuilder could potentially reference itself during its own
initialization if a valid insertion point was left around and a
new basic block was created. Move basic block creation after the
initializer instead.
* CSDiag was comparing canonical types for equality directly, which
leads to mixed-type comparisons if one side of the comparison is nullptr.
Use isEqual instead.
The -enable-testing flag makes ValueDecl::getEffectiveAccess()
say that internal declarations are public.
This would lead us to emit spurious diagnostics if a default
argument of an internal function referenced a private symbol,
for example, which is something we actually want to allow.
This is a second revision of the patch -- instead of changing
getEffectiveAccess() to take an extra parameter, this changes
getFormalAccessScope() instead.
Fixes <rdar://problem/32592973>.
The -enable-testing flag makes ValueDecl::getEffectiveAccess()
say that internal declarations are public.
This would lead us to emit spurious diagnostics if a default
argument of an internal function referenced a private symbol,
for example, which is something we actually want to allow.
Hack around this by adding a new 'forLinkage' parameter to
getEffectiveAccess(). When this is false, we ignore the
-enable-testing flag, and only look for the @_versioned
attribute.
I'm not very happy with the fix, because it only compliates
the subtle behaviors of getFormalAccess(), getEffectiveAccess()
and getFormalAccessScope() further. But refactoring this is
a bigger change than I'm willing to put into swift-4.0-branch.
Fixes <rdar://problem/32592973>.
- Unqualified lookup was incorrectly checking generic arguments even
when resolving interface types, resulting in a bogus 'Self does
not conform to P' error when referencing a generic typealias from
inside a protocol.
- The generic argument check was also done incorrectly if the
underlying type did not contain any type parameters, resulting
in bogus ErrorTypes. Just remove the no-type-parameter
"optimization" instead, since it was working around another
crash.
- When opening up a generic typealias in the constraint solver, we
did the wrong thing if the generic typealias was defined in a
protocol, producing concrete substitutions for the parent type
instead of a 'Self := ParentType' substitution.
Fixes <rdar://problem/32633645>.
