When looking up the decl context of a type, ASTDemangler has to take
into account that there are multiple different modules where that type
could've come from. This is due to two facts:
- Thanks to the `-module-abi-name` flag, multiple modules can share
the same ABI name (which is the module name that is usually used when
mangling a type).
- In some situations mangling can use the module's real name, for
example, when mangling for the debugger or USRs coupled with @_originallyDefinedIn.
rdar://134095412
This conforms mutable C++ container types, such as `std::vector`, to `MutableCollection` via a new overlay protocol `CxxMutableRandomAccessCollection`.
rdar://134531554
Fix a bug that swift clang importer is not setup correctly when prefix
map is used. There are two separate issues:
* CC1 args used to setup clang import when building swift (interface and
sources) are not correctly remapped.
* When loading SDKInfo from SDK path, the SDKSettings.json is not
loading from VFS, thus the file cannot be loaded from remapped path.
rdar://134458611
When referencing a declaration, check whether any of the types in that
reference are unsafe. This can diagnose cases where the original
declaration either wasn't actually unsafe, or is being provided with
unsafe types via generics.
Unlike all of the other build configuration checks, `canImport` has
side effects including the emission of various diagnostics. Thread a
source location through here so the diagnostics end up on the right
line.
In the accepted proposal for SE-0421, `next(_:)` became `next(isolation:)`.
Some of the references to that method in the codebase need to be updated
accordingly.
The stdlib module can end up being a non-null ModuleDecl that contains
no files, due to a failure to load the stdlib.
In such an unusual case, fall-back to synthesizing Copyable/Escapable
into the Builtin module so that Sema can proceed.
rdar://129092011
It should no longer be necessary to provide an `@_alwaysEmitIntoClient` version
of `_diagnoseUnavailableCodeReached()`. This workaround was originally added to
provide compatibility with projects that were misconfigured to compile against
a newer stdlib but link against an older one.
Resolves rdar://119892482.
There was a bunch of logic to lazily populate replacement types
corresponding to reducible generic parameters. This didn't seem
to have a clear purpose so let's remove it.
Fix the problem that when the only module can be found is an
invalid/out-of-date swift binary module, canImport and import statement
can have different view for if the module can be imported or not.
Now canImport will evaluate to false if the only module can be found for
name is an invalid swiftmodule, with a warning with the path to the
module so users will not be surprised by such behavior.
rdar://128876895
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
Teach dependency scanner to report all the module canImport check result
to swift-frontend, so swift-frontend doesn't need to parse swiftmodule
or parse TBD file to determine the versions. This ensures dependency
scanner and swift-frontend will have the same resolution for all
canImport checks.
This also fixes two related issues:
* Previously, in order to get consistant results between scanner and
frontend, scanner will request building the module in canImport check
even it is not imported later. This slightly alters the definition of
the canImport to only succeed when the module can be found AND be
built. This also can affect the auto-link in such cases.
* For caching build, the location of the clang module is abstracted away
so swift-frontend cannot locate the TBD file to resolve
underlyingVersion.
rdar://128067152
A type's mangled name will store the module's ABI name, not the module's
regular name. When reconstructing a type from a mangled name, the
demangler needs to take that into account.
rdar://126953614
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
It is no longer true that the existential signature of `any P` is
always just `<Self where Self: P>`, because `P` might be `~Copyable`,
in which case `any P` is really `any P & Copyable`.
Just remove the micro-optimization here, because if we're building
an existential signature, we're likely going to be doing generic
signature queries, and then we'll need a Requirement Machine anyway.
This happened to manifest in the SIL optimizer when performing the
concrete existential peephole with `any Sendable`, since Sendable is
now ~Copyable.
Fixes rdar://problem/126079282.
