In one place we were calling hasError() and in another directly checking
for ErrorType; if we had a type containing an ErrorType as a structural
component, we would hit an assertion.
We have a hack where we use the ParsedDecl as the DeclContext,
to handle completion during function signature parsing, which
happens before the FuncDecl has been created.
While fixing this properly would require a bigger change to the
parser and AST, for now we just check if the ParsedDecl is a
child context of CurDeclContext, and only use it then.
Complete generic parameters and their members inside generic where
clauses on structs, classes, enums, extensions, typealiases, funcs,
subscripts and inits.
Still not handled correctly are associatedtypes.
rdar://problem/20582394
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.
`FreeTypeVariableBinding::GenericParameters` mode allowed to bind
all free type variables with fresh generic parameter types, which
is incorrect (at least) if there are multiple generic solutions
present, because such parameters couldn't be compared.
This mode was used for code completion, which is now switched to use
`FreeTypeVariableBinding::UnresolvedType` instead.
This doesn't give particularly useful information yet (i.e. Self isn't
listed, see rdar://problem/31981641 ), but it does stop the completion
code from just directly crashing.
Fixes rdar://problem/31981486.
Swift 3 supported limited argument destructuring when it comes to
declaring (trailing) closures. Such behavior has been changed by
SE-0110. This patch aims to provide better error message as well
as fix-it (if structure of the expected and actual arguments matches)
to make the migration easier and disambiguate some of the common
mistakes.
Resolves: SR-4738, SR-4745, rdar://problem/31892961.
When performing a name lookup from inside of a protocol
or extension, skip directly to the source file context
when we are done visiting the protocol or extension.
Otherwise, if we have invalid code where the protocol
or extension is nested inside another type, we might
find a member whose type contains generic parameters
of the outer type; these parameters will not resolve,
since we do not model protocols or extensions nested
inside generic contexts (yet?).
This supercedes an earlier workaround for a similar
issue; the new workaround fixes more crashes.
This is needed to avoid crasher regressions with an
upcoming patch.
* [stdlib] String : RangeReplaceableCollection & BidirectionalCollection
* Add source compatibility hack for Swift.max
* Add source compatibility hack for Swift.min
* Remove redundant conformance in benchmarks
* Fix stupid typo I thought I'd already pushed
* XFAIL testing now-redundant conformance
* XFAIL an IDE test for now
The unfixed ones were discovered by fuzzing. I have fixes for most
of them in an in-progress PR.
One that was already fixed is just a regression test I'm adding.
- In functions called from resolveType(), consistently
use a Type() return value to indicate 'unsatisfied
dependency', and ErrorType to indicate failure.
- Plumb the unsatisfiedDependency callback through the
resolution of the arguments of BoundGenericTypes, and
also pass down the options.
- Before doing a conformance check on the argument of a
BoundGenericType, kick off a TypeCheckSuperclass request
if the type in question is a class. This ensures we don't
recurse through NominalTypeDecl::prepareConformanceTable(),
which wants to see a class with a valid superclass.
- The ResolveTypeOfDecl request was assuming that
the request was satisfied after calling validateDecl().
This is not the case when the ITC is invoked from a
recursive call to validateDecl(), hack this up by returning
*true* from isResolveTypeDeclSatisfied(); otherwise we
assert in satisfy(), and we can't make forward progress
in this case anyway.
- Fix a bug in cycle breaking; it seems if we don't invoke
the cycle break callback on all pending requests, we end
up looping forever in an outer call to satisfy().
- Remove unused TR_GlobalTypeAlias option.
The GenericTypeOrArchetypeResolver changes are effectively porting
some existing hacks from the now-dead
PartialGenericTypeOrArchetypeResolver, which dodges some regressions
in the compiler-crashers suite and fixes 11 new crashers. There is
undoubtedly a more principled approach to fix these problems, most of
which now step from recursively looking for a generic environment that
isn't there, but doing so requires improvements to our name lookup.
The generic environment of a GenericTypeToArchetypeResolver may be
`nullptr`, as returned by DeclContext::getGenericEnvironmentOfContext,
during prechecking of closure expressions at the necessarily non-generic
top level.
Fixes a couple of crashers.
RFC 2279 states that, in UTF-8:
"The octet values FE and FF never appear."
RFC 3629 states that, in UTF-8:
"The octet values C0, C1, F5 to FF never appear."
Generalize the check to advance past invalid starting bytes for
a UTF-8 sequence to fix a crash in the lexer.
The tentantive parse is used for diagnostic purposes but can cause code-completion to delay the same decl twice.
The range of CodeCompletionExpr was previously character range which invalidated invariants of the AST.
Fixes:
validation-test/IDE/crashers_fixed/084-swift-parser-consumedecl.swift
validation-test/IDE/crashers_fixed/104-swift-gettypeofcompletioncontextexpr.swift
With erroneous code, such as in code-completion, it's not safe to assume
that the constructor is inside a nominal decl context.
rdar://problem/28867794
We already fail early on a missing body in normal type-checking, but we
missed the case where we call typeCheckAbstractFunctionBodyUntil
directly, as in code-completion.
rdar://problem/28822204
