namespace.
This moves the `isInMacroArgument` predicate and `lookupMacros` into `namelookup`.
ASTScope still encapsulates the scope tree and contains the operation to lookup
the enclosing macro scope, which then invokes a callback to determine whether a
potential macro scope is indeed a macro, because answering this question requires
name lookup.
There's still plenty of more work to do here for
pattern diagnostics, including introducing a
bunch of new locator elements, and handling things
like argument list mismatches. This at least lets
us fall back to a generic mismatch diagnostic.
Previously we would wait until CSApply, which
would trigger their type-checking in
`coercePatternToType`. This caused a number of
bugs, and hampered solver-based completion, which
does not run CSApply. Instead, form a conjunction
of all the ExprPatterns present, which preserves
some of the previous isolation behavior (though
does not provide complete isolation).
We can then modify `coercePatternToType` to accept
a closure, which allows the solver to take over
rewriting the ExprPatterns it has already solved.
This then sets the stage for the complete removal
of `coercePatternToType`, and doing all pattern
type-checking in the solver.
This shouldn't be necessary, we should be able to
solve with type variables instead. This makes sure
we don't end up with weird special cases that only
occur when an external type is present.
Order them such that if they were changed to
conversions, they would be sound. This shouldn't
make a difference, but unfortunately it turns out
pattern equality is not symmetric. As such, tweak
the pattern equality logic to account for the
reversed types. This allows us to remove a special
case from function matching.
The TypedPattern and IsPattern constraints were
incorrectly written, with conversions propagating
out of the patterns, when really conversions
ought to propagate into patterns. In any case, it
seems like we really want equality here. Fix the
constraints to use equality, and have the cast
constraint operate on the external pattern type
instead of the subpattern type.
Before this change it was possible to:
1. Call mutating methods on a consume result.
2. assign into a consume (e.x.: var x = ...; (consume x) = value.
From an implementation perspective, this involved just taking the logic I
already used for the CopyExpr and reusing it for ConsumeExpr with some small
tweaks.
rdar://109479440
Some notes:
1. I implemented this as a contextual keyword that can only apply directly to
lvalues. This ensures that we can still call functions called copy, define
variables named copy, etc. I added tests for both the c++ and swift-syntax based
parsers to validate this. So there shouldn't be any source breaks.
2. I did a little bit of type checker work to ensure that we do not treat
copy_expr's result as an lvalue. Otherwise, one could call mutating functions on
it or assign to it, which we do not want since the result of copy_value is
3. As expected, by creating a specific expr, I was able to have much greater
control of the SILGen codegen and thus eliminate extraneous copies and other
weirdness than if we used a function and had to go through SILGenApply.
rdar://101862423
Rather than eagerly binding them to holes if the
sequence element type ends up being Any, let's
record the CollectionElementContextualMismatch fix,
and then if the patterns end up becoming holes,
skip penalizing them if we know the fix was
recorded. This avoids prematurely turning type
variables for ExprPatterns into holes, which
should be able to get better bindings from the
expression provided. Also this means we'll apply
the logic to non-Any sequence types, which
previously we would give a confusing diagnostic
to.
* Use fancy arrows (`→`) because they are distinct from and shorter than `->`,
and fancier.
* We have two ways of demarcating locators: `@ <locator>` and `[[<locator>]];`.
Stick to the first, which is shorter and clearer.
* 'attempting type variable' → 'attempting binding'. *Bindings* are attempted,
not type variables.
* `considering ->` → `considering:`. I think a colon is semantically more fit
and makes things easier to read if the considered constraint has arrows in its
description or types. It’s also shorter this way.
In Swift 5 and earlier initializer references are handled in a special
way that uses a type variable to represent a type of the parameter
list. Such type variables should be allowed to bind to a pack expansion
type to support cases where initializer has a single unlabeled variadic
generic parameter - `init(_ data: repeat each T)`.
Delay constraint generation for capture list until body of
the associated closure is resolved. This means that we can
unify capture checking with that of regular pattern bindings
for multi-statement closures.
element environments.
This allows the constraint system to ensure that for a given pack expansion locator,
the given shape class is always the same when requesting the element environment.
If the shape class differs, it means there's a same-shape requirement failure, which
will be diagnosed via the ShapeOf constraint simplification.
Provide ASTWalker with a customization point to specify whether to
check macro arguments (which are type checked but never emitted), the
macro expansion (which is the result of applying the macro and is
actually emitted into the source), or both. Provide answers for the
~115 different ASTWalker visitors throughout the code base.
Fixes rdar://104042945, which concerns checking of effects in
macro arguments---which we shouldn't do.
`addExplicitConversionConstraint` generates a disjunction to check
whether type could be coerced via bridging. That is not useful for
literal initialization which could use direct equality if the type
of cast is valid because necessary conformance checks have been
performed before the transformation.
