Also restore some diagnostics in TypeCheckType that should have
migrated with the attributes. In particular, diagnose cases where
we have @autoclosure with any function type repr with a non-Void
input type.
Resolves SR-5296
Using these in declaration position has been deprecated and
removed in Swift 3. These attributes were not being parsed and
contained deadweight diagnostics that should have been moved
when these attributes became type attributes.
We want the type of a KeyPathExpr to be the specific *KeyPath<T, U> subclass appropriate for the literal, with upcasts to a more general contextual type, since we rely on that invariant elsewhere to extract the base and projected value types. Fixes SR-5008 | rdar://problem/32395076.
While trying to diagnose problems related to keypath components
don't assume that type of the component is always correct, check
before trying to see if it's bridged type or has members.
Resolves: rdar://problem/33135487
- Deinitializers never get a custom Objective-C name.
- Classes and protocols are never bridged themselves; that only matters
for structs and enums.
This avoids another circularity issue like the one in a8bc132565,
where the Clang importer ends up importing a class and hands it to the
type checker, which then asks about conformances. The conformance
lookup table goes to add the extension from the Swift module, except
that the Swift module is what asked for the import in the first place.
It's possible there's a more general solution here, but this
particular change is good even in the non-crashy cases, and definitely
safe for Swift 4.0. Even if the test case is even more idiosyncratic
than the last one.
The test case change for SourceKit is probably due to the first
category not triggering the import of the other two
categories. Changes in import order have been known to affect source
compatibility, though not frequently. However, categories are not
intended to be ordered in the first place. There's still more we can
do in this space, and implicitly depending on these calls /outside/ of
the importer to control category import order was quite brittle
anyway.
SR-5330 / rdar://problem/32677610
Change the fix-it to move the argument to its correct location in one go. This happens by removing it from one location and inserting it in the other (as opposed to the original implementation which swapped one argument with the preceding one). The commas separating the arguments are adjusted to match the moved argument.
Add new tests for reordering regular arguments, variadic arguments, and function arguments.
Resolves: SR-4715 rdar://problem/31849281
Use ArchetypeResolutionKind::CompleteWellFormed whenever we need to
ask questions about the potential archetype, and
ArchetypeResolutionKind::WellFormed when we need only evaluate whether
there is a legitimate type with that name (and possibly get a handle
to it).
Fixes crasher in diagnostics related to the fact that contextual type
is not always available when trying to diagnose problems related to
calls with trailing closures.
Resolves: rdar://problem/33067102
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.
In anticipation of future attributes, and perhaps the ability to
declare lvalues with specifiers other than 'let' and 'var', expand
the "isLet" bit into a more general "specifier" field.
Rather than pretend that the requirement signature of a protocol is a
full, well-formed generic signature that one can meaningfully query,
treat it as a flat set of requirements. Nearly all clients already did
this, but make it official. NFC
Using the attribute in this position is a relic from the Swift 2
days, and fixing it required letting invalid code fall through to
Sema instead of being diagnosed in Parse proper. Treat 'var'
in this position like 'let' by simply offering to remove it
instead of extracting it into a separate variable.
When type-checking switch statements with patterns let's
check if we have an optional type and try to see if the case
exists in its base type, if so we can suggest a fix-it.
Resolves: rdar://problem/32241441
Relax restriction placed on the function shadowing diagnostics
and allow such diagnostics to be emitted even when argument types
do not match expected parameter types, but use "near match" message
in that case to clarify that shadowing is not exact.
Resolves: rdar://problem/32854314
PotentiallArchetype::getNestedType(Identifier...) was using
ArchetypeResolutionKind::AlwaysPartial, even though only one client
(the code that itself handles AlwaysPartial) needed it. Add an
ArchetypeResolutionKind parameter to pass through, updating clients
accordingly.
Eliminates 5 effective uses of AlwaysPartial. Only two left!
When trying to diagnose problems related to calls where
function is represented by a member of nominal type let's
attempt to be more cautious while type-checking function
expression without it's arguments, because it could produce
unrelated diagnostics.
Resolves: rdar://problem/32551313, rdar://problem/28456467, rdar://problem/31671195
* Simplify TupleTypeRepr parsing
This patch introduces a TupleTypeReprElement struct that holds the
locations for all relevant bits of tuple elements. It removes the
NameLoc and UnderscoreLoc arrays from TupleTypeReprElement in favor of
holding each of these on TupleTypeReprElement. These extra bits of info
are required for full-fidelity representation in the Syntax library.
* Remove TupleTypeReprBitfields and move EllipsisLoc out of TrailingObjects
* Update users of TupleTypeRepr
* Don't resize the elts if we're going to push_back
* getType -> getElementType
* Move ellipsis back into TrailingObjects.
* Move NumElements into TupleTypeReprBitfields
An early exit introduced in PR #10292 meant that we would only record
a protocol conformance as "used" in the first file in which we saw a
reference to the conformance. Make sure we record the conformance as
used in each source file that needs it. Fixes rdar://problem/32978891
and rdar://problem/32980176.
Currently some contextual errors are discovered too late
which leads to diagnostics of unrelated problems like argument
mismatches, these changes attempt to improve the situation
and try to diagnose contextual errors related to calls
before everything else.
Resolves: SR-5045, rdar://problem/32934129
When gathering constraints for a type variable, we were gathering all of
the constraints for the members of the equivalence class, and then for
the adjacencies of the representative of the equivalence class, but not
from the adjacencies of other members of the equivalence class.
For example for:
#3 = $T3
#4 = $T4 equivalent to $T3
#5 = $T5 as $T4.Element
after binding $T3 we would collect the constraints related to $T3 and
$T4, but not $T5. The end result can be that we finish examining all
disjunctions and type bindings but still have inactive constraints in
the constraint graph, which is treated as a failure in the solver.
Fixes SR-5120 / rdar://problem/32618740.
