The closures are type-checked after macros are expanded
which means that macro cannot reference any declarations
from inner or outer closures as its arguments.
For example:
`_: (Int) -> Void = { x in { @Macro(x) in ... }() }`
`x` is not going to be type-checked at macro expansion
time and cannot be referenced by `@Macro`.
Let's walk up declaration contexts until we find first
non-closure one. This means that we can support a local
declaration that is defined inside of a closure because
they are separately checked after outer ones are already
processed.
We use experimental features to let people know that the construct is
subject to change and users should not rely on this unless they are
willing to rewrite the uses of this feature later. However, in compiler
generated code everything should be fair game, we will update the
compiler when these features change. This is a requirement to be able to
turn safe wrapper generation on by default.
[Swiftify][StrictMemorySafety] Test `unsafe` warnings in wrappers (NFC)
As _SwiftifyImport now emits the `unsafe` keyword to prevent warnings
about unsafe code in the macro expansions, we should make sure that our
tests do not emit any warnings. It turns out that calls to
RawSpan::withUnsafeRawPointer are not recognised as unsafe, so we
sometimes get warnings about using `unsafe` on a safe expression. This
issue is tracked under rdar://145899513.
The generated safe wrappers need to call unsafe code. Make sure those
calls are qualified with unsafe to avoid warnings that are not
actionable (users cannot fix them).
[ClangImporter][Swiftify] merge importBoundsAttributes with importSpanAttributes and support lifetime bounds for __counted_by
- [ClangImporter] Merge paths for std::span and __counted_by
importBoundsAttributes and importSpanAttributes are merged into a single
function named swiftify. This allows us to not have to duplicate the
effort of attaching _SwiftifyImport macros, but is also necessary to
allow importing a function with both __counted_by and std::span types.
- [ClangImporter] Enable parsing bounds safety attributes in C++
This allows combining __counted_by and std::span for safe interop.
Previously we disabled this in C++ mode due to issues when bounds
attributes occurred directly or indirectly in templated contexts, but
this has now been resolved on the clang side.
- [Swiftify] Emit Span for counted_by return values with lifetime info
__counted_by return values with .lifetimeDependence are now mapped to
Span instead of UnsafeBufferPointer. Also fixes bug where std::span
return values would map to Span even if lifetime dependence info was
missing.
__counted_by return values with .lifetimeDependence are now mapped to
Span instead of UnsafeBufferPointer. Also fixes bug where std::span
return values would map to Span even if lifetime dependence info was
missing.
Usage of Span was temporarily behind an experimental feature flag. Now
that SE-0447 has been accepted, remove the experimental feature flag and
allow Span usage everywhere.
Implements rdar://144819992.
Unfortunately, this was not discovered earlier as swift-ide-test is not
invoking the SIL passes that produce this diagnostic. When creating
Swift spans from C++ spans we have no lifetime dependency information to
propagate as C++ spans are modeled as escapable types. Hence, this PR
introduces a helper function to bypass the lifetime checks triggered by
this discepancy. Hopefully, the new utility will go away as the lifetime
analysis matures on the Swift side and we get standardized way to deal
with unsafe lifetimes.
https://github.com/swiftlang/swift/pull/72659 turned out to have some
source compatibility fallout that we need to fix. Instead of introducing
yet another brittle compatibility hack, stop emitting errors about a
missing `any` altogether until a future language mode.
Besides resolving the compatibility issue, this will encourage
developers to adopt any sooner and grant us ample time to gracefully
address any remaining bugs before the source compatibility burden
resurfaces.
A subsequent commit adds a diagnostic group that will allow users to
escalate these warnings to errors with `-Werror ExistentialAny`.
When a macro that has both 'member' and 'extension' roles is on a type,
and both list conforming protocols, the order in which those roles were
evaluated in the compiler could change the set of protocols passed to
the macro expansion function (via `conformingTo:`). Specifically, if
the extension macro was expanded first, the member macro would see the
extension providing the conformance to one of its protocols, and not
pass down that protocol to the member macro's `conformingTo:`.
Ensure that we account for already-expanded extension macros that
define conformances.
Fixes rdar://137080876.
When we generate a safe wrapper that only differs in the return type we
might introduce ambiguities as some callers might not have enough
information to disambiguate between the overloads. This PR makes sure
the newly generated declarations are marked as @_disfavoredOverload so
the compiler can keep calling the old functions without a source break
when the feature is turned on.
rdar://139074571
Support adding safe wrappers for APIs returning std::span depending on
the this object. This also fixes an issue for APIs with 0 parameters.
rdar://139074571
This PR adds basic support for storing lifetime dependence information,
transform Span return types, and generate lifetime annotations.
rdar://139074571
* Fix mismatch on 'FixIt.Change.replace' between several application
implementations. Specifically '.replace' should includes the trivia.
* Ignore no-op 'FixIt.Change.replace{Leading|Trailing}Triviia'.
* Import __counted_by for function return values
Instead of simply passing a parameter index to _SwiftifyInfo, the
_SwiftifyExpr enum is introduced. It currently has two cases:
- .param(index: Int), corresponding to the previous parameter index
- .return, corresponding to the function's return value.
ClangImporter is also updated to pass this new information along to
_SwiftifyImport, allowing overloads with buffer pointer return types to
be generated. The swiftified return values currently return Span when
the return value is marked as nonescaping, despite this not being sound.
This is a bug that will be fixed in the next commit, as the issue is
greater than just for return values.
* Fix Span variant selection
There was an assumption that all converted pointers were either
converted to Span-family pointers, or UnsafeBufferPointer-family
pointers. This was not consistently handled, resulting in violating the
`assert(nonescaping)` assert when the two were mixed. This patch removes
the Variant struct, and instead each swiftified pointer separately
tracks whether it should map to Span or UnsafeBufferPointer.
This also fixes return pointers being incorrectly mapped to Span when
marked as nonescaping.
We previously missed diagnosing this for macro
args, fixing it turned out to be a bit more source
breaking than initially thought though, so downgrade
to a warning until Swift 7.
rdar://141963700
A previous PR already added support to the SwiftifyImport macro to
generate safe wrappers. This PR makes ClangImporter emit the macro to do
the transformation.
This makes it possible to mark a pointer with __sized_by when the
pointee type definition is not included. The wrapper function has the
same interface as if the parameter were a void pointer, since the stdlib
has no `OpaqueBufferPointer` type.
* use swift-ide-test for checking interop signatures
* add xfail test for Span + Optional combo (Optional requires Escapable)
This is a preliminary PR to transform nonescaping std::span parameters
to Swift's Span type in safe wrappers. To hook this up with
ClangImporter, we will need generalize the noescape attribute to
non-pointer types (PR is already in review). To transform potentially
escaping spans and spans in the return position, a follow-up PR will
add lifetime annotation support. This is a building block towards
rdar://139074571.
* Make pointer bounds non-experimental
* Rename @PointerBounds to @_SwiftifyImport
* Rename filenames containing PointerBounds
* Add _PointerParam exception to stdlib ABI test
* Add _PointerParam to stdlib API changes
* Rename _PointerParam to _SwiftifyInfo
Since the introduction of custom attributes (as part of property
wrappers), we've modeled the context of expressions within these
attributes as PatternBindingInitializers. These
PatternBindingInitializers would get wired in to the variable
declarations they apply to, establishing the appropriate declaration
context hierarchy. This worked because property wrappers only every
applied to---you guessed it!---properties, so the
PatternBindingInitializer would always get filled in.
When custom attributes were extended to apply to anything for the
purposes of macros, the use of PatternBindingInitializer became less
appropriate. Specifically, the binding declaration would never get
filled in (it's always NULL), so any place in the compiler that
accesses the binding might have to deal with it being NULL, which is a
new requirement. Few did, crashes ensued.
Rather than continue to play whack-a-mole with the abused
PatternBindingInitializer, introduce a new CustomAttributeInitializer
to model the context of custom attribute arguments. When the
attributes are assigned to a declaration that has a
PatternBindingInitializer, we reparent this new initializer to the
PatternBindingInitializer. This helps separate out the logic for
custom attributes vs. actual initializers.
Fixes https://github.com/swiftlang/swift/issues/76409 / rdar://136997841
The mangling of macro expansions relies on having a type-checked AST
for its enclosing context. When that enclosing context is within a
local context (say, a local type), mangling would trigger type
checking of that local type, which could then involve assigning local
discriminators. However, if this happens before type checking of the
enclosing function body, we would end up failing to assign closure
discriminators to (e.g.) autoclosures within the body.
The fundamental problem here is the interaction between discriminator
assignment (which can only happen after type checking) and mangling of
macro expansion buffers (which can happen during that type checking).
Break this cycle by providing a different approach to mangling macro
expansions within local contexts as the innermost non-local context +
a name-based discriminator within that local context. These manglings
are not ABI and are not stable, so we can adjust them later if we come
up with a scheme we like better. However, by breaking this cycle, we
eliminate assertions and miscompiles that come from missing
discriminators in this case.
Fixes rdar://139734958.
The `DebugDescription` macro has been accepted. Additionally, the `DebugDescriptionMacro` feature was not providing conditional declaration as I originally intended. References to the feature are not needed and can be removed.
(cherry-picked from #77738)
Since we can't do a proper "deep" clone of expression nodes, cloning
such a CustomAttr is necessarily shallow. In such cases, don't cache
the swift_attr source files at all, so we get fresh attribute nodes
for each such usage.
Introduce a number of fixes to allow us to fully use declarations that
are produced by applying a peer macro to an imported declarations.
These changes include:
* Ensuring that we have the right set of imports in the source file
containing the macro expansion, because it depends only on the module
it comes from
* Ensuring that name lookup looks in that file even when the
DeclContext hierarchy doesn't contain the source file (because it's
based on the Clang module structure)
Expand testing to be sure that we're getting the right calls,
diagnostics, and generated IR symbols.
Previously, they were being parsed as top-level code, which would cause
errors because there are no definitions. Introduce a new
GeneratedSourceInfo kind to mark the purpose of these buffers so the
parser can handle them appropriately.
Instead, ensure we walk into expressions in
SyntacticDiagnosticWalker, allowing
`performStmtDiagnostics` to be called there for
all statements present in the target. This avoids
a case where we'd double diagnose.
While here, inherit the walker from
BaseDiagnosticWalker.
I missed this in my previous PR, but this is needed
to ensure we visit macro arguments for macro expansion
exprs that have substitute MacroExpansionDecls since
we prefer to visit the arguments on the decl once
the expression has been expanded.
