[cxx-interop] Make ClangDeclExplicitSafety request non-recursive
[cxx-interop] Do not import template type arguments
[cxx-interop] Check template argument safety in ClangDeclExplicitSafety
Introduce a last resort check reporting references to
implementation-only dependencies that would appear in the generated
swiftmodule. This check is applied at serialization, long after
exportability checking applied at typechecking. It should act as a back
stop to references missed by typechecking or @_implementationOnly decls
that should have been skipped.
This check is gated behind CheckImplementationOnlyStrict and should be
used with embedded only.
rdar://160697599
Printing shouldn't rely on parameter declaration bit because it only
works in cases when there is an explicit `nonisolated(nonsending)`
modifier on the type.
Always print `nonisolated(nonsending)` before `sending`, `@escaping`
and other declaration attributes/modifiers to avoid parsing issues.
Resolves: rdar://164267736
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.
Before this patch we referred to builtin names in SILGenBuiltin using raw c
strings. This can lead to potential spelling mistakes yielding bugs. Rather than
doing this, I stole a technique that we use in other parts of the compiler:
constexpr StringLiteral generation using CPP macros. Specifically, I defined in
Builtins.h a new namespace called BuiltinNames and inside of BuiltinNames I used
CPP macros to define a StringLiteral for each Builtin. Thus one can get the
appropriate name for a Builtin by writing:
```
BuiltinNames::Sizeof
```
instead of writing "Sizeof". I also cleaned up the code a little by adding for
functions that take identifiers an additional overload that takes a StringRef
and converts the StringRef to an identifier internally. This just eliminates
unnecessary code from call sites by moving them into the callee.
Always run explicit `Sendable` checks on public types and suppress
warning printing by default instead of using a special compiler argument.
Resolves: rdar://162394810
Don't consider implicitly exposed memory layouts when checking for
usable from inline correctness. That check applies only to memory
layouts marked as exposed explicitly. Consider the implict state only at
the general availability checking.
In non-library-evolution mode, gated behind the CheckImplementationOnly
feature flag, report references to structs marked with
`@_implementationOnly` from a fragile context. Preventing references
from inlinable functions and structs not marked `@_implementationOnly`.
This fixes the following tests which are now crashing due to hitting
unreachable "no buffer containing location found" in
`SourceManager::findBufferContainingLoc`:
- attr/attr_dynamic_member_lookup.swift
- AutoDiff/Sema/DerivativeRegistrationCrossModule/main.swift
- Constraints/construction.swift
- Constraints/members.swift
- NameLookup/accessibility.swift
- Sema/call_as_function_simple.swift
The root cause of the crash is as follows. All the tests involve
emitting `InaccessibleMemberFailure` error diagnostic (see
`InaccessibleMemberFailure::diagnoseAsError`). When `DeclNameLoc
nameLoc` is initialized via default constructor and is not re-assigned
with smth meaningful later, the check `nameLoc.isValid()` returns `true`
even though it should be `false`. It turns out that we treat `const void
*LocationInfo` as `SourceLoc` and hope that if `LocationInfo` is
`nullptr`, casting this to `SourceLoc` would produce a "default"
`SourceLoc` with `Pointer` member set to `nullptr`. But such a cast (see
`getSourceLocs()` member of `DeclNameLoc`) is undefined behavior. So,
the compiler assumes that `Pointer` member of `SourceLoc` we try to cast
to is not `nullptr` (due to strict aliasing rule), which leads to
`nameLoc.isValid()` being mistakenly computed as `true`.
This patch resolves the issue by handling this special case separately.
Emit a proper diagnostic for a conformance that is not available due to
custom availability that doesn't have version information, eliminating
an assertion.
This is necessary because we need to model its stack-allocation
behavior, although I'm not yet doing that in this patch because
StackNesting first needs to be taught to not try to move the
deallocation.
I'm not convinced that `async let` *should* be doing a stack allocation,
but it undoubtedly *is* doing a stack allocation, and until we have an
alternative to that, we will need to model it properly.
