This commit changes how we represent caller-side
default arguments within the AST. Instead of
directly inserting them into the call-site, use
a DefaultArgumentExpr to refer to them indirectly.
The main goal of this change is to make it such
that the expression type-checker no longer cares
about the difference between caller-side and
callee-side default arguments. In particular, it
no longer cares about whether a caller-side
default argument is well-formed when type-checking
an apply. This is important because any
conversions introduced by the default argument
shouldn't affect the score of the resulting
solution.
Instead, caller-side defaults are now lazily
type-checked when we want to emit them in SILGen.
This is done through introducing a request, and
adjusting the logic in SILGen to be more lenient
with ErrorExprs. Caller-side defaults in primary
files are still also currently checked as a part
of the declaration by `checkDefaultArguments`.
Resolves SR-11085.
Resolves rdar://problem/56144412.
The name-lookup behavior that avoids looking for members of a nominal type
or extension therefore when resolving the inheritance clause is now
handled by UnqualifiedLookup, so remove it from the type checker itself.
Fixes rdar://problem/39130543.
Wire up the request-evaluator with an instance in ASTContext, and
introduce two request kinds: one to retrieve the superclass of a class
declaration, and one to compute the type of an entry in the
inheritance clause.
Teach ClassDecl::getSuperclass() to go through the request-evaluator,
centralizing the logic to compute and extract the superclass
type.
Fixes the crasher from rdar://problem/26498438.
* Reject bad string interpolations
String interpolations with multiple comma-separate expressions or argument labels were being incorrectly accepted.
* Tweak error name to match message
* Diagnose empty interpolations more clearly
* Don’t double-diagnose parse errors
Fixes a test at Parse/recovery.swift:799 which the previous commit broke.
* Fix incorrect test RUN: line
A previous version of this test used FileCheck instead of -verify, and the run line wasn’t properly corrected to use -verify.
* Update comment
* Add more argument label tests
Ensures that we don’t get different results from an initializer that doesn’t exist or doesn’t take a String.
* Resolve the SR-7958 crasher test
We now diagnose the error and remove the label before it has an opportunity to crash.
Trying to use an argument label in an interpolation can cause various crashes. In swiftlang-1000.0.16.7, these are usually in SILGen; in master at 8f6028d, they’re in CSApply.
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
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.
If unqualified name lookup finds an associated type, but resolution to
the type witness fails, produce a diagnostic rather than silently
failing. Fixes the crash in SR-5825, SR-5881, and SR-5905.
It's conceivable that we could resolve this with suitably global
associated type inference... but that's far off and it's best not to
crash until then.
CSDiag was misinterpreting the result of checkGenericArguments().
A result of SubstitutionFailure does not mean a diagnostic was
emitted, only a result of Failure means that. This fixes a case
where we did not emit a diagnostic, result in a crash on invalid.
The diagnostic is still poor, but that's better than crashing.
Fixes <https://bugs.swift.org/browse/SR-5932>,
<rdar://problem/34522739>.
The small-but-significant change to the generic signature builder is
to refuse to create unresolved potential archetypes. Instead, delay
any requirement that depends on such type, to be reprocessed once
we've seen all of the other requirements. If the type can be resolved
later, it will be; Otherwise, the type checker will complain when it
sees an unresolvable type. By itself, this fixes the crash in SR-2796.
Doing this by itself regresses diagnostics because typo correction in
the generic signature builder no longer kicks in. Therefore, implement
typo correction for these cases in the type checker proper, using its
existing facilities for typo correction. The result is more consistent
code with a better result.
Fixes SR-2796 / rdar://problem/28544316.
When a concrete requirement is invalid due to the concrete type
lacking a conformance to a particular, required protocol, don't emit
that incorrect requirement---it causes invalid states further down the
line.
Fixes SR-5014 / rdar://problem/32402482.
While here, fix a comment that Huon noticed trailed off into oblivion.
Centralize and simplify the handling of conformance requirements
resolved by same-type-to-concrete requirements in a few ways:
* Always store a ProtocolConformanceRef in via-superclass and
via-concrete requirement sources, so we never lose this information.
* When concretizing a nested type based on its parent, use the
via-concrete conformance information rather than performing lookup
again, simplifying this operation considerably and avoiding
redundant lookups.
* When adding a conformance requirement to a potential archetype that
is equivalent to a concrete type, attempt to find and record the
conformance.
Fixes SR-4295 / rdar://problem/31372308.
Rather than performing typo correction at the very end of finalize(),
do it as part of delayed requirement handling when we cannot otherwise
make progress. This is a cleaner way to cope with typo correction that
gives us a better chance of getting to a sane result.
Fixes rdar://problem/31048352 by eliminating the need for tracking the
number of unresolved potential archetypes altogether. Fixes
rdar://problem/32077627.
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>.
