Specifically, the two routines we were importing relatively were:
1. TypeChecker::conformsToProtocol. I moved this onto a helper routine on
SILType.
2. swift::findOriginalValueType(Expr *). This routine just looks through various
implicit conversions to find the original underlying type. I moved it to a
helper method on Expr.
Previously we would only base the start loc on the
`SubExpr`, but that isn't set until CSApply. Change
it to take both `SubExpr` and `Body`'s source range
into account.
Also tighten up the invariant that a TapExpr must
be created with a non-null BraceStmt.
This is a futile attempt to discourage future use of getType() by
giving it a "scary" name.
We want people to use getInterfaceType() like with the other decl kinds.
This patch migrates the compiler off of the deprecated LLVM APIs where I
can.
- APInt::getAllOnesValue -> APInt::getAllOnes
- APInt::getNullValue -> APInt::getZero
- APInt::isNullValue -> APInt::isZero
- APInt::getMinSignedBits -> APInt::getSignificantBits
- clang::Module::submodule_{begin,end} -> clang::Module::submodules
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
'MacroExpansionDecl' and 'MacroExpansionExpr' have many common methods.
Introduce a common base class 'FreestandingMacroExpansion' that holds
'MacroExpansionInfo'.
Factor out common expansion logic to 'evaluateFreestandingMacro'
function that resembles 'evaluateAttachedMacro'.
Setting closure and local discriminators depends on an in-order walk
of the AST. For macros, it was walking into both macro expansions and
arguments. However, this doesn't work well with lazy macro expansions,
and could result in some closures/local variables not getting
discriminators set at all.
Make the assignment of discriminators only walk macro arguments, and
then lazily assign discriminators for anything within a macro
expansion or in ill-formed code. This replaces the single global "next
autoclosure discriminator" scheme with a per-DeclContext scheme, that
is more reliable/robust, although it does mean that discriminators
of closures and locals within macro expansions are dependent on
ordering. That shouldn't matter, because these are local values.
Fixes rdar://108682196.
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
- Allow an if/switch expression to become an
implicit return of a function that has a `#if`
body with a single active element that is an `if`
or `switch`.
- Allow `#if` branches of an if/switch expression,
as long as there is a single active expression
element.
rdar://107487977
Sometimes we build a `MacroExpansionDecl` from a `MacroExpansionExpr`.
Sometimes we do it the other way. In both cases, we risk the two
copies of must-by-shared data (macro arguments, resolved macro
reference, etc.) getting out-of-sync.
Instead, share the storage between the two representations when we
create one from the other, so that they cannot get out-of-sync. This
allows us to eliminate the extremely-dodgy `cacheOutput` call earlier.
Allow freestanding macros to be used at top-level.
- Parse top-level `#…` as `MacroExpansionDecl` when we are not in scripting mode.
- Add macro expansion decls to the source lookup cache with name-driven lazy expansion. Not supporting arbitrary name yet.
- Experimental support for script mode and brace-level declaration macro expansions: When type-checking a `MacroExpansionExpr`, assign it a substitute `MacroExpansionDecl` if the macro reference resolves to a declaration macro. This doesn’t work quite fully yet and will be enabled in a future fix.
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.
Look through `try`/`await` markers when looking for
out of place if/switch expressions, and customize
the effect checking diagnostic such that we error
that `try`/`await` are redundant on `if`/`switch`
expressions.
Introduce SingleValueStmtExpr, which allows the
embedding of a statement in an expression context.
This then allows us to parse and type-check `if`
and `switch` statements as expressions, gated
behind the `IfSwitchExpression` experimental
feature for now. In the future,
SingleValueStmtExpr could also be used for e.g
`do` expressions.
For now, only single expression branches are
supported for producing a value from an
`if`/`switch` expression, and each branch is
type-checked independently. A multi-statement
branch may only appear if it ends with a `throw`,
and it may not `break`, `continue`, or `return`.
The placement of `if`/`switch` expressions is also
currently limited by a syntactic use diagnostic.
Currently they're only allowed in bindings,
assignments, throws, and returns. But this could
be lifted in the future if desired.
Introduce discriminators into freestanding macro expansion expressions
and declarations. Compute these discriminators alongside closure and
local-declaration discriminators, checking them in the AST verifier.
With macro expansions, and really any code generation that produces
proper source locations, the parent source file of a declaration
context will be a generated source file rather than the source file
near the top of the declaration-context stack. Adjust the
implementation of `getParentSourceFile()` to return that innermost
source file by doing location-based lookup.
There are some cases of severely malformed code where we cannot compute
closure discriminators appropriate. Introduce a fallback to use the
unstable global numbering of discriminators in this case.
Rather than set closure discriminators in both the parser (for explicit
closures) and then later as part of contextualizing closures (for
autoclosures), do so via a request that sets all of the discriminators
for a given context.
