This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
This source location will be used to determine whether to add a name lookup
option to exclude macro expansions when the name lookup request is constructed.
Currently, the source location argument is unused.
When performing an implicit module build, the frontend was prepending
`-target-min-inlining-target target` to the command line. This was overriding
the implicit `-target-min-inlining-target min` argument that is implied when
`-library-level api` is specified. As a result, the wrong overload could be
picked when compiling the body of an inlinable function to SIL for emission
into the client, potentially resulting in crashes when the client of the module
is back deployed to an older OS.
Resolves rdar://109336472
This attribute was commented out in the private swiftinterface for
backwards compatibility with older compilers unaware of the attribute.
This scenario shouldn't be a problem anymore and without that attribute
some imports can raise errors. Let's print the attribute as it was
written in the sources without commenting it out.
Not aliasing the stdlib should allows it to be used in inlinable code.
Since builtin isn't imported explicitly, references to it shouldn't use
the alias.
rdar://104582241
Introduce a new behavior when printing references to modules with an
`export_as` definition. Use the `export_as` name in the public swiftinterface
and the real module name in the private swiftinterface.
This has some limits but should still be an improvement over the current
behavior. First, the we use the `export_as` names only for references to clang
decls, not Swift decls with an underlying module defining an `export_as`.
Second, we always print the `export_as` name in the public swiftinterface,
even in the original swiftinterface file when the `export_as` target is likely
not know, so that generated swiftinterface is still broken.
This behavior is enabled by the flags `-enable-experimental-feature ModuleInterfaceExportAs`
or the `SWIFT_DEBUG_USE_EXPORTED_MODULE_NAME_IN_PUBLIC_ONLY` env var. We may
consider turning it on by default in the future.
rdar://98532918
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
In AliasModuleNames, avoid wrongfully printing aliased names for modules
that were not aliased. This can happen in the case of modules indirectly
imported via a reexport.
rdar://102262019
If there's a reference in API to a module that's not imported, the
import is inserted automatically in the swiftinterface. This ensures the
inserted import is correctly aliased in AliasModuleNames mode.
Ambiguities are introduced in generated swiftinterfaces when a type
shares a name with a module (i.e. XCTest). This workaround uses the
module-alias feature to avoid these ambiguities. Writing module
references with a distinguishable prefix should allow normal
type-checking to avoid the usual ambiguities.
We should still aim for a proper fully-qualified named syntax, but this
may help in the mean time.
rdar://101969500
"Extra" protocols from a superclass are already handled when printing the superclass, so we should not accumulate them when recording protocols for a subclass.
Resolves rdar://98523784
Erroneous declaration attributes were sometimes being printed in the private swiftinterfaces of modules because the changes from https://github.com/apple/swift/pull/42276 were effectively corrupting the attribute list for any decl with sythesized conformances (e.g. `Equatable`, `Hashable`). It is necessary to clone the attributes before adding them to the synthesized conformance extension decls.
Resolves rdar://94009296
This path was not exercised in the test suite, and when the
PrimaryAssociatedTypes feature finally (incorrectly) triggered it,
it would print '#endifextension'.
and make `@_unsafeInheritExecutor` a suppressible feature.
Some language features are required in order to parse a
declaration correctly, but some can safely be ignored.
For the latter, we'd like the module interface to simply
contain the declaration twice, once with the feature and
once without. Some basic support for that was already
added for the SpecializeAttributeWithAvailability feature,
but it didn't interact correctly with required features
that might be checked in the same `#if` clause (it simply
introduced an `#else`), and it wasn't really set up to
allow multiple features to be handled this way. There
were also a few other places that weren't updated to
handle this, presumably because they never coincided
with a `@_specialize` attribute.
Introduce the concept of a suppressible feature, which
is anything that the ASTPrinter can modify the current
PrintOptions in order to suppress. Restructure the
printing of compatibility checks so that we can print
the body multiple times with different settings.
Print required feature checks in an outer `#if...#endif`,
then perform a separate `#if...#else...#endif` within
if we have suppressible features. If there are multiple
suppressible features, check for the most recent first,
on the assumption that it will imply the rest; then
perform subsequent checks with an `#elsif` clause.
This should be a far more solid foundation on which to
build compatibility checks in the future.
`@_unsafeInheritExecutor` needs to be suppressible
because it's been added to some rather important
existing APIs. Simply suppressing the entire decl will
effectively block old tools from using a new SDK to
build many existing projects (if they've adopted
`async`). Dropping the attribute changes the semantics
of these functions, but only if the compiler features
the SE-0338 scheduling change; this is a very narrow
window of main-branch development builds of the tools,
none of which were officially released.
It's been quite a long time since this unused parameter was introduced.
The intent is to produce the module as a root for the search - that is,
computing the set of conformances visible from that module, not the set
of conformances inside of that module. Callers have since been providing
all manner of module-scoped contexts to it.
Let's just get rid of it. When we want to teach protocol conformance
lookup to do this, we can revert this commit as a starting point and try
again.
Start treating the null {Can}GenericSignature as a regular signature
with no requirements and no parameters. This not only makes for a much
safer abstraction, but allows us to simplify a lot of the clients of
GenericSignature that would previously have to check for null before
using the abstraction.
Don't print indirect conformances for protocols that are
implementation-only imported. Indirect conformances are synthesized when
the middle protocol is internal and not printed in the swiftinterface.
This logic didn't previously check for implementation-only imports,
likely because type-checking usually forbids it. Let's still protect
this use case as we are considering relaxing this type-checking
restriction in the future.
rdar://78718838
The patch introduces a new setting instead of changing existing settings
because the generated interfaces in the IDE have slightly different
requirements; the extended type there is unconditionally not printed
qualified (even if it is ambiguous). This is likely because the
ambiguity heuristic is very weak; it doesn't even do name lookup.
Simplifying that logic would be nice, but then we'd need to update
a bunch of IDE/print* tests and end up with more more visual clutter
in the IDE.
Introducing the new setting means we can change the behavior for
swiftinterface files without affecting the behavior for IDE interfaces.
Fixes rdar://79093752.
Titled as "// swift-module-flags-ignorable:", this new field contains new
frontend arguments that can be safely ignored by the older version of the compiler.
For compilers that don't know the field at all, all arguments in it are ignored.
rdar://78233352
Extend the checks for marker protocols and rethrows protocols to ensure
that we #if out more code that relies on them in module interface
generation. This makes the _Concurrency module parseable by much older
compilers.
Fixes rdar://75291705.
There is a known issue with module interfaces where a type with the same name as a module will disrupt references to types in that module. Fully fixing it will require a new language feature (SR-898) which is not yet available. In the meantime, module interfaces support a workaround flag (“-Xfrontend -module-interface-preserve-types-as-written”) which prints an alternate form that usually works. However, you have to know to add this flag, and it’s not obvious because nothing breaks until a compiler tries to consume the affected module interface (or sometimes even one of its clients).
This commit emits a warning during module interface emission whenever the module interface either imports a type with the same name as the module being built, or declares a type with the same name as a visible module. This lets the user know that the type may cause problems and they might need to implement a workaround.
When generating a module interface, emit `#if` around any declarations
that are tied to specific, named language features. This allows module
interfaces to be processed by older Swift compilers that do not
support these newer features, such as async/await or actors.
The amount of effort required to correctly handle a new kind of
feature varies somewhat drastically based on the feature itself. The
"simple" case is where a particular declaration can only exist if a
feature is available. For example, and `async` declaration is fairly
easy to handle; a `@_marker` protocol's conformances are not.
Fixes rdar://73326633.
