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 existing _SwiftifyImport macro is a peer macro, limiting it to only
emitting function wrappers in the same scope as the original function.
Protocols cannot contain function implementations, so these need to be
placed in a separate protocol extension instead. _SwiftifyImportProtocol
is an extension macro rather than a peer macro, to enable this
functionality.
Rather than operating on a single function, like _SwiftifyImport,
_SwiftifyImportProtocol takes information about multiple methods and
creates a single protocol extension with all wrappers in a one-shot
operation.
rdar://144335990
This adds a check in lit.local.cfg for whether the current C++ stdlib
contains the 'span' header. If so, the llvm-lit feature 'std_span' is
set. Also adds 'REQUIRES: std_span' to interop tests that include
'span'. This means we no longer have to choose between blanket disabling
`std::span` tests on all Linux distributions, or listing every Linux
distro with a libstdc++ version without `std::span` support as
unsupported.
I couldn't find any existing path to the MSVC stdlib in lit, and we
don't test versions of MSVC old enought to not support std::span
anyways, so 'std_span' is unconditionally enabled when targeting
windows-msvc.
rdar://161999160
rdar://161999174
rdar://162106580
rdar://162106619
rdar://162106643
rdar://162106653
rdar://162106722
rdar://162106747
Remove the DeclContext parameter from ResolveMacroRequest, we can now
retrieve the DeclContext either from the CustomAttr or macro expansion
expr/decl directly.
Macro implementation should receive only see the macro syntax (i.e.
`#macroName(...)` or `@macroName(...)` are operator folded, not other
syntax - the attached declration, member, etc.
rdar://162208759
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.
The initializers for RawSpan and UnsafeRawBufferPointer take an
UnsafeRawPointer, so when the underlying function returns an
OpaquePointer we need to cast it first.
rdar://162091516
Although the type is unsafe, the count is marked `@safe`, and this use
of `unsafe` results in a warning (regardless of whether strict memory
safety is enabled or not).
Keep emitting `unsafe` when the pointer buffer is wrapped in Optional
for now however, because that is currently flagged as unsafe.
rdar://162416566
When shutting down, the plugin, we send SIGTERM, then wait(2) on it. But
we observed some cases the compiler waits for the plugin process exit
for long time.
To resolve that, send an empty message to the plugin and let them exit
itself.
rdar://160820381
These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
Thread the static build configuration (formed from language options) in
to the macro plugin handler, which will serialize it for use in the
macro implementation. test this with a simple macro that checks
whether a particular custom configuration (set via `-D`) is enabled or
not.
This required some re-layering, sinking the logic for building a
StaticBuildConfiguration from language options down into a new
swiftBasicSwift library, which sits on top of the C++ swiftBasic and
provides Swift functionality for it. That can be used by the C++
swiftAST to cache the StaticBuildConfiguration on the ASTContext,
making it available for other parts of ASTGen.
The test is implicitly using `async` main so the `SwiftStdlib 5.1`
checks weren't actually preventing it from exercising the concurrency
runtime. Just require the runtime to be present.
This test case failed in CI when using a strict diff, because the output
also contained the text "swift runtime: unknown backtracing setting
'warnings'". Switch to using FileCheck to ignore this output.
Since freestanding macro expansion buffer names include the line number
of their invocation, it can become quite fiddly to try to update a test
file with multiple macro expansions. This adds the option to use an
expected-expansion block and use a relative line number, nesting other
expected diagnostic statements inside this block.
Example syntax:
```swift
let myVar = #myMacro
/*
expected-expansion@-2:1{{
expected-error@13:37{{I can't believe you've done this}}
expected-note@14:38{{look at this and ponder your mistake}}
}}
*/
```
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
Also mark them as not executable, since they don't call `%target-run`.
This is needed in back deployment configurations where StringProcessing is
not supported.
Addresses rdar://159635486
The previous message was just suggesting unchecked Sendable, but instead
we should be suggesting to add final to the class. We also don't
outright suggest using unchecked Sendable -- following
https://github.com/swiftlang/swift/pull/81738 precedent.
Resolves rdar://155790695
Sema seems to be flagging inout expressions (e.g. &foo) in expression
macros as invalid, setting up a catch 22 where Sema emits an error when
a parameter has the '&' sigil and type checking fails when it doesn't.
This resolves the issue by allowing inout expressions inside macro
expansion expressions.
Resolves https://github.com/swiftlang/swift/issues/82369.
We can't assume that type-checking the expression macro in the
parameter will also fail if it fails at the call site since e.g
name lookup may differ. Make sure we only apply this logic to simple
literals.
rdar://154771596
Previously we would emit a macro that would error on expansion when
trying to add a safe wrapper to a function with __sized_by on a type
that mapped to UnsafePointer<T> instead of UnsafeRawPointer or
OpaquePointer. __sized_by is acceptable when used on byte-sized pointee
types, so this adds machinery in the macro expansion to support that.
Meanwhile on the ClangImporter side, we add a check so that __sized_by
on pointee types with a size is ignored if that size is larger than 1
byte.
When _SwiftifyImport applies .sizedBy to a pointer of type
UnsafePointer<T> it will still map it to a
RawSpan/UnsafeRawBufferPointer in the safe overload. The assumption is
that any API using __sized_by is dealing with raw bytes, so raw pointers
are a better Swift abstraction than UnsafePointer<CChar> etc. It also
lets the user avoid doing a scary pointer cast from some potentially
larger-than-byte-sized pointer to a byte-sized pointer. Casts to
RawPointers are generally safer and more ergonomic.
rdar://150966684
rdar://150966021
Previously we did not remove count parameters if any count parameters
were shared between count expressions, or if any count expression
contained operations. Buffer sizes were also just checked to be larger
than or equal than the given count.
We now extract the count from Spans/BufferPointers whenever possible,
and store that value in a variable at the start of the function. If
multiple parameters share the same count, a bounds check is emitted to
make sure that they have the same size. Subspans can be used if one span
is larger than necessary.
The message in the bounds check is changed so that it includes the
expected and actual value, to aid in debugging.
This patch also fixes some incorrect indentation, and adds the
Whitespace.swift test case to act as a regression test in case the
indentation changes, since the other test cases don't use significant
whitespace.
rdar://151488820
rdar://151511090
rdar://146333006
rdar://147715799
