Once the '@escaping' bit is removed from TupleTypeElt, it no longer makes
sense to print argument lists as if they were TupleTypes or ParenTypes,
since function types are '@escaping' by default inside tuples but not
in argument lists.
Instead, print ArrayRef<AnyFunctionType::Param> directly. For now this
introduces some awkward usages of AnyFunctionType::decomposeInput();
these will go away once the AST is changed to represent the argument list
as a list of expressions and not a single tuple expression.
Right now we use TupleShuffleExpr for two completely different things:
- Tuple conversions, where elements can be re-ordered and labels can be
introduced/eliminated
- Complex argument lists, involving default arguments or varargs
The first case does not allow default arguments or varargs, and the
second case does not allow re-ordering or introduction/elimination
of labels. Furthermore, the first case has a representation limitation
that prevents us from expressing tuple conversions that change the
type of tuple elements.
For all these reasons, it is better if we use two separate Expr kinds
for these purposes. For now, just make an identical copy of
TupleShuffleExpr and call it ArgumentShuffleExpr. In CSApply, use
ArgumentShuffleExpr when forming the arguments to a call, and keep
using TupleShuffleExpr for tuple conversions. Each usage of
TupleShuffleExpr has been audited to see if it should instead look at
ArgumentShuffleExpr.
In sequent commits I plan on redesigning TupleShuffleExpr to correctly
represent all tuple conversions without any unnecessary baggage.
Longer term, we actually want to change the representation of CallExpr
to directly store an argument list; then instead of a single child
expression that must be a ParenExpr, TupleExpr or ArgumentShuffleExpr,
all CallExprs will have a uniform representation and ArgumentShuffleExpr
will go away altogether. This should reduce memory usage and radically
simplify parts of SILGen.
This PR migrates instance member on type and type member on instance diagnostics handling to use the new diagnostics framework (fixes) and create more reliable and accurate diagnostics in such scenarios.
Currently that has been limited only to expressions which aren't
flagged as `TCC_ForceRecheck`, but it should be extended to all
sub-expressions, otherwise we might produce invalid diagnostics
in `PreCheckExpression`.
Solving Bind is a little easier than Equal. The only remaining uses of Equal
are in the .member syntax and keypaths; if we can refactor those, we might be
able to simplify LValue handling in the type checker in general.
Try to fix constraint system in a way where member
reference is going to be defined in terms of its use,
which makes it seem like parameters match arguments
exactly. Such helps to produce solutions and diagnose
failures related to missing members precisely.
These changes would be further extended to diagnose use
of unavailable members and other structural member failures.
Resolves: rdar://problem/34583132
Resolves: rdar://problem/36989788
Resolved: rdar://problem/39586166
Resolves: rdar://problem/40537782
Resolves: rdar://problem/46211109
Fix to use subscript operator instead of spelled out name helps
to produce a solution, that makes it much easier to diagnose
problems precisely and provide proper fix-its, it also helps to
diagnose ambiguous cases, and stacks up nicely with other errors.
Sometimes constraint solver fails without producing any diagnostics,
it could happen during different phases e.g. pre-check, constraint
generation, or even while attempting to apply solution. Such behavior
leads to crashes down the line in AST Verifier or SILGen which are
hard to diagnose.
Let's guard against that by tracking if solver produced any diagnostics
upon its failure and if no errors were or are scheduled to be produced,
let's produce a fallback fatal error pointing at affected expression.
Resolves: rdar://problem/38885760
All of the open existentials should be removed, along with their
opaque value expressions, after sub-expression type-check. Because
diagnostics might pick next sub-expression from constraint and its
anchor could point to sub-expression which has only opaque value
without enclosing open existential, which is going to trip up sanitizer.
Resolves: rdar://problem/46544601
After calling `get{Possible}Type{s}WithoutApplying` types have to be
re-cached afterwards because sanitizer (run as part of the constraint
generator) can mutate AST to e.g. re-introduce member references.
Resolves: rdar://problem/46497155
Context archetypes and opened existential archetypes differ in a number of details, and this simplifies the overlapping storage of the kind-specific fields. This should be NFC; for now, this doesn't change the interface of ArchetypeType, but should allow some refinements of how the special handling of certain archetypes are handled.
When parameter refers to something undefined its type is going to
be `ErrorType`, so diagnostic path needs to make sure that parameter
has a valid function type before trying to extract result from it.
Resolves: rdar://problem/46377919
In #7530, NominalTypeDecl::lookupDirect() started returning TinyPtrVector instead of ArrayRef so that it wouldn’t be returning a pointer into a mutable data structure. Unfortunately, some callees assigned its return value into an ArrayRef; C++ happily converted the TinyPtrVector to an ArrayRef and then treated the TinyPtrVector as out-of-scope, so the ArrayRef would now point to an out-of-scope object. Oops.
