Attribute @_silgen_name is today only allowed to be used on functions, this change allows usage on globals as well. The motivation for that is to be able to "forward declare" globals just like it's today possible to do with functions (for the cases where it's not practical or convenient to use a bridging header).
Separately, this change also adds a @_silgen_name(raw: ...) syntax, which simply avoids mangling the name (by using the \01 name prefix that LLVM uses). The motivation for that is to be able to reference the "magic Darwin linker symbols" that can be used to look up section bounds (in the current dylib/module) -- those symbols don't use the underscore prefix in their mangled names.
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
IDE inspection can delay parsing of particular declarations, so expanding
ASTScopes during the first pass will miss those declarations. Clear any
expanded scopes to force re-expansion during the second pass.
The parser is currently responsible for adding local type declarations
to a `SourceFile`, which IR generation later queries. However, IRGen
never sees the source files associated with macro expansion buffers,
so local types introduced there don't get recorded.
In time, this approach of using the parser to record semantic
information should be replaced with something more "pull" oriented.
For now, however, record local type declarations in the outermost
enclosing source file... so we see the ones produced by macro
expansions, too.
Fixes rdar://109370309.
'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'.
Direct lookup relied in primary file checking to have filled in the
protocol type stored in the ImplementsAttr. This was already wrong
with multi-file test cases in non-WMO mode, and crashed in the
ASTPrinter if printing a declaration in a non-primary file.
I don't have a standalone test case that is independent of my
upcoming ASTPrinter changes, but this is a nice cleanup regardless.
API development sometimes requires a redesign while supporting early
adopters. Currently this is done by adding @_spi(name) to the API but
that requires adding the attribute in import statements as well, causing
manual overhead of adding and then removing when the redesign is done.
This PR introduces a special spi group name '_' and allows an implicit
spi import of a module containing API attributed with '@_spi(_)'
Resolves rdar://109797632
* Add @_used and @_section attributes for global variables and top-level functions
This adds:
- @_used attribute that flags as a global variable or a top-level function as
"do not dead-strip" via llvm.used, roughly the equivalent of
__attribute__((used)) in C/C++.
- @_section("...") attribute that places a global variable or a top-level
function into a section with that name, roughly the equivalent of
__attribute__((section("..."))) in C/C++.
There is a modeling difference between the swift-syntax tree and the
C++ type representation (TypeRepr) that is a little odd here, so we
end up parsing the ellipsis on the C++ side rather than looking "up"
the syntax tree to find it.
Introduce a new experimental feature `ASTGenTypes` that uses ASTGen to
translate the Swift syntax tree (produced by the new Swift parser)
into C++ `TypeRepr` nodes instead of having the C++ parser create the
nodes.
The approach here is to intercept the C++ parser's `parseType`
operation to find the Swift syntax node at the given position (where
the lexer currently is) and have ASTGen translate that into the
corresponding C++ AST node. Then, we spin the lexer forward to the
token immediately following the end of the syntax node and continue
parsing.
Avoid parsing the syntax tree up-front, and instead
only parse it when required, which happens when either:
1. ASTGen parsing is enabled (currently disabled
by default)
2. Round trip checking is enabled for a primary
file (enabled by default in a debug build,
except when dep scanning or doing an IDE
operation)
3. We need to evaluate a macro in that file
This change therefore means that we now no longer
need to parse the syntax tree for secondary files
by default unless we specifically need to evaluate
a macro in them (e.g if we need to lookup a member
on a decl with an attached macro). And the same
for primaries in release builds.
rdar://109283847
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
