Address a few related issues that affect local types and opaque result types within macros:
* Don't add local types or opaque types encountered while parsing the
arguments of a freestanding macro to the global list. When we do add
them, make sure we're adding them to the outermost source file so
they'll get seen later. This avoids trying to generate code for these
types, because they aren't supposed to be part of the program. Note
that a similar problem remains for arguments to attached macros, which
will need to be addressed with a more significant refactoring.
* When determining whether opaque types should be substituted within a
resilience domain, check the outermost source files rather than the exact
source file, otherwise we will end up with a mismatch in
argument-passing conventions.
* When delaying the type checking of functions that occur as part of a
macro expansion, make sure we record them in the outermost Swift source
file. Otherwise, we won't come back to them.
There is a common theme here of using AST state on the source file in
a manner that isn't ideal, and starts to break down with macros. In
these cases, we're relying on side effects from earlier phases
(parsing and type checking) to inform later phases, rather than
properly expressing the dependencies through requests.
Fixes rdar://110674997&110713264.
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
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.
If we have an identifier followed by either `[` or
a generic argument list, avoid turning it into a
binding pattern, as that would be invalid. This
is similar to the existing rule we have where a
following `(` prevents a binding pattern from
being formed.
This allows patterns such as `let E<Int>.foo(x)` and
`let (y[0], x)` to compile, where `x` is treated
as a binding, but no other identifier is.
rdar://108738034
Initialization expressions are not allowed on computed properties
but if a property has `init` accessor it should be allowed because
it could be used by a memberwise initializer.
Allow keywords after `#` in freestanding macro expansions
There is no reason why we shouldn’t allow keywords here.
I also thought about allowing keywords after `@` but things become tricky here for two reasons:
- In the parser, we parse a type after the `@`, which could start with a keyword itself (e.g. `any`). If we want to keep the parser logic to parse a type after `@` (which I think we should), then it becomes unclear what `@any T` should parse as.
- We allow a space between `@` and the type name. This makes it very hard for recovery to tell whether `@ struct` refers to an attribute with name `struct` or if the user forgot to write the attribute name after `@`.
Since almost all keywords are lowercase and attached member macros are usually spelled with an uppercase name, there are a lot fewer chances for clashes here, so I don’t think it’s worth allowing keywords after `@`.
https://github.com/apple/swift/issues/66444
rdar://110472060
'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'.
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
* Unify macro expansion parsing logic between MacroExpansionExpr and
MacroExpansionDecl
* Diagnose whitespace between '#' and the macro name
* Diagnose keyword as a macro name
* Parse `#<identifier>` attribute list as a `MacroExpansionDecl`
regardless of the position
* Diagnose whitespaces between `#` and the macro name.
* Correctly attach attributes to `MacroExpansionDecl`
* Fix `OrigDeclAttributes` to handle modifiers (use `getLocation()`
instead of `AtLoc`.)
Type checking is a TODO
rdar://107386648
I want to reserve Feature::MoveOnly only for move-only types and other
things that are part of SE-390. Other prototyped features like
noimplicitcopy and some older names for consume were left behind
as guarded by this Feature. That's really not the right way to do it,
as people will expect that the feature is enabled all the time, which
would put those unofficial features into on-by-default. So this change
introduces two new Features to guard those unofficial features.
The MSVC 2019 14.29 toolset seems to not properly handle the member variable reference in this case. Workaround this by explicitly using the `this` identifier to indicate that we would like to access the member variable. This is repaired in newer toolsets, however, the CI is currently using the older toolset.
Cursor info only cares about the `doneParsing` callback and not about all the `complete` functions that are now defined in `CodeCompletionCallbacks`. To make the design clearer, split `IDEInspectionCallbacks`.
rdar://105120332
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.
In my earlier commit that attempted to do this I wasn't aggressive enough. In
this commit, I was more aggressive in putting it behind a flag and as a result
we reject all of the patterns in the tests I added into tree.
This fixes an issue if the range ends with a string literal that contains the IDE inspection target. In that case the end of the range will point to the start of the string literal but the IDE inspection target is inside the string literal and thus after the range’s end.
Extend handling of incomplete multi-line string literals during input in
REPL to also cover raw multi-line strings.
Fixes#52840 and apple/llvm-project#4628
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.
pack expansion type reprs.
Classic variadic parameters still use the postfix ellipsis syntax, and
pack expansion types now use a prefix 'repeat' keyword.
Always parse macro expansions, regardless of language mode, and
eliminate the fallback path for very, very, very old object literals
like `#Color`. Instead, check for the feature flag for macro
declaration and at macro expansion time, since this is a semantic
restriction.
While here, refactor things so the vast majority of the macro-handling
logic still applies even if the Swift Swift parser is disabled. Only
attempts to expand the macro will fail. This allows us to enable the
macro-diagnostics test everywhere.
