Implement the @export(implementation) and @export(interface) attributes
to replace @_alwaysEmitIntoClient and @_neverEmitIntoClient. Provide a
warning + Fix-It to start staging out the very-new
@_neverEmitIntoClient. We'll hold off on pushing folks toward
@_alwaysEmitIntoClient for a little longer.
Allow external declaration of global variables via `@_extern(c)`. Such
variables need to have types represented in C (of course), have only
storage (no accessors), and cannot have initializers. At the SIL
level, we use the SIL asmname attribute to get the appropriate C name.
While here, slightly shore up the `@_extern(c)` checking, which should
fix issue #70776 / rdar://153515764.
Currently, normal globals are represented as a PatternBindingDecl and a VarDecl in the AST, directly under the SourceFile:
```
// var variable_name = 42, compiled with -parse-as-library
(source_file ...
(pattern_binding_decl ...
(pattern_entry ...
(pattern_named ... "variable_name") ...
(var_decl "variable_name" ...
```
Top-level globals are represented more like local variables, under a TopLevelCodeDecl. Note that the VarDecl is still at the file scope. In SILGen, this case has some special handling to use the a storage of a global variable, and to avoid cleanups (see `emitInitializationForVarDecl`). Effectively, this means the globals are initialized inside the `main` function.
```
// var variable_name = 42, compiled without -parse-as-library
(source_file ...
(top_level_code_decl ...
(brace_stmt ...
(pattern_binding_decl ...
(pattern_named ... "variable_name") ...
(var_decl "variable_name" ... top_level_global
```
SE-0492 needs top-level globals that have a `@section` annotation to behave like a normal global -- initialization must happen statically, and not in `main`. This PR changes the parsing of those globals to match normal globals, without the TopLevelCodeDecl wrapper. SILGen and IRGen then handles them correctly.
Removes the underscored prefixes from the @_section and @_used attributes, making them public as @section and @used respectively. The SymbolLinkageMarkers experimental feature has been removed as these attributes are now part of the standard language. Implemented expression syntactic checking rules per SE-0492.
Major parts:
- Renamed @_section to @section and @_used to @used
- Removed the SymbolLinkageMarkers experimental feature
- Added parsing support for the old underscored names with deprecation warnings
- Updated all tests and examples to use the new attribute names
- Added syntactic validation for @section to align with SE-0492 (reusing the legality checker by @artemcm)
- Changed @DebugDescription macro to explicitly use a tuple type instead of type inferring it, to comply with the expression syntax rules
- Added a testcase for the various allowed and disallowed syntactic forms, `test/ConstValues/SectionSyntactic.swift`.
The legacy parser has a special case for code like `fn(:)` which corrects it to `fn(_:)`, but the new `::` token was interfering with cases where there were two adjacent colons (e.g. `fn(::)`). Correct this issue.
.swiftinterface sometimes prints a pattern binding initializer and the
accessor block. However the parser doesn't expect such constructs and
the disambiguation from trailing closures would be fragile. To make it
reliable, introduce a disambiguation marker `@_accessorBlock` .
`ASTPrinter` prints it right after `{` only if 1) The accessor block is
for a pattern binding declaration, 2) the decl has an initializer
printed, and 3) the non-observer accessor block is being printed. In the
parser, if the block after an initializer starts with
`{ @_accessorBlock`, it's always parsed as an accessor block instead of
a trailing closure.
rdar://140943107
Clients should be able to handle closures without a valid `in`
SourceLoc, let's avoid setting it to a recovery location. This avoids
crashing in cases where we set an `in` loc that's after the closure's
end loc.
Introduce CustomAttrOwner that can store either a Decl for an
attached attribute, or a DeclContext for e.g a type or closure
attribute. Store this on CustomAttr such that we can query it from
the name lookup requests.
Teach the parser to recognize a top-level '->' in a closure as a signature and
produce a targeted diagnostic ("expected 'in' after the closure signature")
instead of treating it as a type expression.
Adds a parser test:
- test/Parse/closure-missing-in.swift
Updates existing test with the new diagnostic:
- test/Parse/type_expr.swift
Resolves: swiftlang/swift#59928
The intent for `@inline(always)` is to act as an optimization control.
The user can rely on inlining to happen or the compiler will emit an error
message.
Because function values can be dynamic (closures, protocol/class lookup)
this guarantee can only be upheld for direct function references.
In cases where the optimizer can resolve dynamic function values the
attribute shall be respected.
rdar://148608854
In Swift 6 and later, whitespace is no longer permitted between an
attribute name and the opening parenthesis. Update the parser so that
in Swift 6+, a `(` without preceding whitespace is always treated as
the start of the argument list, while a '(' with preceding whitespace is
considered the start of the argument list _only when_ it is unambiguous.
This change makes the following closure be parsed correctly:
{ @MainActor (arg: Int) in ... }
rdar://147785544
- Turn `BindExtensionsForIDEInspectionRequest` into the main extension
binding request.
- Change `ExtendedNominalRequest` such that it's no longer what
extension binding calls into to do the name lookup, instead it calls
directly into `computeExtendedNominal`. `getExtendedNominal` can
then be the entrypoint for `ExtendedNominalRequest` and assumes that
extension binding has already run. This avoids needing to fake the
dependency relationship in the DeclChecker.
This can help work around problems when the names of a C++ declaration
and a Swift declaration would collide, or to temporarily work around
compiler bugs.
rdar://152838988&140802127&158843666
Also '#error', '#warning', and '#sourceLocation'.
Other call-like syntax (call expression, macro expansion, and custom
attribtues) requires '(' on the same line as the callee. For consistency,
built-in attributes and built-in directives should also ignore '(' on
next line.
