Cherry pick of #82370 to 6.2 branch.
---
* **Explanation**: Resolves an issue where sema is flagging inout
expressions 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.
* **Risk**: Low. It allows inout expressions in one additional context.
* **Testing**: Tested by lit tests, including new tests for the newly
allowed expression.
* **Issue**: rdar://153840234
* **Reviewer**: @slavapestov
* **Main branch PR**: https://github.com/swiftlang/swift/pull/82370
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 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
(cherry picked from commit f5fa481205)
Previously we would only add @_disfavoredOverload if the only type
changed was the return type, because in any other case it is unambiguous
which overload to call. However it is still ambiguous when storing the
function as a value rather than calling the function, unless explicit
type annotations are used.
To avoid breaking any existing code, this patch adds
@_disfavoredOverload to every overload generated by @_SwiftifyImport.
rdar://151206394
(cherry picked from commit 0f312adb92)
Parameters can be named with keywords without escaping, because it's
unambiguous in the grammar that they are parameters. They still need to
escaped when referred to inside the function body however. This escapes
all references to parameters using backticks.
Parameter names are also checked for clashes with the function name - in
such cases the parameter is renamed in the same way as unnamed
parameters.
rdar://151024645
(cherry picked from commit ebe2c60f43)
Nullable return Spans did not include __swiftifyOverrideLifetime,
resulting in a lifetime error when returning the Span. Meanwhile return
values for __sized_by did not use the correct label for the call to the
RawSpan initializer, using `count` instead of `byteCount`.
rdar://151804085
rdar://151799287
(cherry picked from commit 526c683)
Due to a bug in how macros on nodes imported from clang are evaluated,
their function body is not always type checked. This forces type
checking before silgen of a macro originating on a node imported from
clang, to prevent crashing in silgen.
rdar://150940383
(cherry picked from commit efd70b1f54)
_SwiftifyImport would expand with syntax errors if applied to a function
with anonymous parameters, because it would try to refer to parameters
using the name `_`. Detect these cases and create names for unnamed
parameters.
rdar://150955944
(cherry picked from commit 8e27947b2a)
This includes changing the feature name so that compilers with the experimental feature don’t accidentally pick up content that only works in the final version.
Resolves rdar://150065196.
Macro expansions are now treated like a part of the source file they belong to, for purposes of the “second declaration is the one that’s diagnosed” rule. This helps stabilize a behavior that was easy to perturb.
[Swiftify] Don't use count from Span inside withUnsafeBufferPointer c… (#81316)
Given a call like: ptr.withUnsafeBufferPointer { _ptrPtr in ... } ptr.count and _ptrPtr.count both contain the same value, but when ptr is a MutableSpan we get an error when referring to ptr inside a call to withUnsafeMutableBufferPointer, so we should use _ptrPtr.count instead.
rdar://150551109
[Swiftify] add _swiftifyOverrideLifetime for return Spans
std::span imports already have _cxxOverrideLifetime for their return
values. __counted_by needs the same, but Cxx may not be available at the
macro site, so we introduce _swiftifyOverrideLifetime in SwiftifyImport.
rdar://150569220
For macro definition checking, we use the range of the `macro`
declaration and re-parse it with `SwiftParser`. Previously it uses the
range including the attributes, but that can result invalid code because
the attribute can be in a `#if ... #endif` region.
Since we don't use attributes for checking the definition, just use the
range without the attributes instead.
rdar://150805795
(cherry picked from commit 8519e71602)
With `ARCMigrate` and `arcmt-test` removed from clang in
https://github.com/llvm/llvm-project/pull/119269 and the new code
migration experience under way (see
https://github.com/swiftlang/swift-evolution/pull/2673), these options
are no longer relevant nor known to be in use. They were introduced
long ago to support fix-it application in Xcode.
For now, turn them into a no-op and emit a obsoletion warning.
(cherry picked from commit 46c394788a84d5932289c71274dd32ea2d61d9dc)
If all of the witnesses to a conformance are nonisolated, then infer that
conformance as nonisolated rather than global-actor-isolated. This is
only relevant when InferIsolatedConformances is enabled, and prevents
that inference to help maintain source compatibility.
Rather than looking for a given BraceStmtScope child for a particular
catch node, check whether the given catch node is the parent of the
innermost BraceStmtScope we've found, looking through an intermediate
source file if needed. This ensures it works correctly when the
BraceStmtScope is in a macro expansion.
rdar://149036108
Downgrade to a warning until the next language mode. This is
necessary since we previously missed coercing macro arguments to
parameter types, resulting in cases where closure arguments weren't
being treated as `async` when they should have been.
rdar://149328745
Previously we would avoid rewriting the arguments in CSApply, but
that can result in incorrect behavior in MiscDiagnostics passes, e.g
incorrectly treating all closure arguments as escaping. Make sure
we rewrite the arguments as we would in regular type-checking.
rdar://148665502
Introduce `PatternBindingCaptureInfoRequest`, and kick it after
contextualizing a property initializer. This ensures it gets run
for stored properties added by macro expansions.
rdar://143429551
If we're using the macro-specific local discriminator, we need to
make sure we avoid mangling the regular local discriminator in
`appendDeclName`, since that could prematurely kick local discriminator
assignment before type-checking has finished.
rdar://143834482
* [Swiftify] Emit Mutable[Raw]Span when possible
Previously wrappers would use UnsafeMutable[Raw]Pointer for mutable
pointers, and Span for non-const std::span, to prevent the compiler from
complaining that MutableSpan didn't exist.
Now that MutableSpan has landed we can finally emit MutableSpan without
causing compilation errors. While we had (disabled) support for MutableSpan
syntax already, some unexpected semantic errors required additional
changes:
- Mutable[Raw]Span parameters need to be inout (for mutation)
- inout ~Escapable paramters need explicit lifetime annotations
- MutableSpan cannot be directly bitcast to std::span, because it is
~Copyable, so they need unwrapping to UnsafeMutableBufferPointer
rdar://147883022
* [Swiftify] Wrap if-expressions in Immediately Called Closures
When parameters in swiftified wrapper functions are nullable, we use
separate branches for the nil and nonnil cases, because
`withUnsafeBufferPointer` (and similar) cannot be called on nil.
If-expressions have some limitations on where they are allowed in the
grammar, and cannot be passed as arguments to a function. As such, when
the return value is also swiftified, we get an error when trying to
pass the if-expression to the UnsafeBufferPointer/Span constructor.
While it isn't pretty, the best way forward seems to be by wrapping the
if-expressions in Immediately Called Closures.
The closures have the side-effect of acting as a barrier for 'unsafe':
unsafe keywords outside the closure do not "reach" unsafe expressions
inside the closure. We therefore have to emit "unsafe" where unsafe
expressions are used, rather than just when returning.
rdar://148153063
Ensure we always expand extension macros after the top-level decl
for the given attached decl. This ensures correct unqualified lookup
behavior, and bans macro implementations from extending the
unqualified name (they're expected to use `providingExtensionsOf`
instead, which uses the qualified name).
rdar://148119538
__counted_by already had MutableSpan support, so add it for std::span
for parity. But since MutableSpan hasn't landed in the standard library
yet, disable emitting it to prevent compilation errors in expansions.
rdar://147882736
Casting the return value to Span must be done outside
withUnsafeBufferPointer, to prevent returning a ~Escapable type from a
function without lifetime info. To do this we sort the transformations
so that the return value transformation is performed last. There was
a bug in the comparison, so the sorting was not always done correctly.
rdar://147934170
When an imported function combines std::span and __counted_by,
std::span would override bounds checks emitted for __counted_by (if it
occurred later in the the parameter list) resulting in no bounds checks
being emitted.
rdar://147883384
Do not rely on the @_unsafeNonescapableResult attribute. That attribute is only
for temporarily working around bugs! And it only affects lifetime diagnostics within
the function. It has no affect on the caller's diagnostics, so it won't solve
this problem:
func macroGeneratedThunk() -> CxxSpan<Int> {
return _unsafeRemoveLifetime(Span...)
}
We cannot simply add @_unsafeRemoveLifetime to the thunk, because SwiftSyntax
does not natively support the attribute. We don't want to add SwiftSyntax
support because this attribute will never be supported syntax!
Instead, use `_overrideLifetime` copying the `Void` type to remove a dependency:
func macroGeneratedThunk() -> CxxSpan<Int> {
return _cxxOverrideLifetime(Span..., copying: ())
}
