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.
Swift string literals are only permitted to contain well-formed UTF-8, but C does not share this restriction, and ClangImporter wasn't checking for that before it created `StringLiteralExpr`s for imported macros; this could cause crashes when importing a header. This commit makes us drop these macros instead.
Although invalid UTF-8 always *did* cause a segfault in my testing, I'm not convinced that there isn't a way to cause a miscompile with a bug like this. If we somehow did generate code that fed ill-formed UTF-8 to the builtin literal init for Swift.String, the resulting string could cause undefined behavior at runtime. So I have additionally added a defensive assertion to StringLiteralInst that any UTF-8 string represented in SIL is well-formed. Hopefully that will catch any non-crashing compiler bugs like this one.
Fixes rdar://67840900.
When looking for a Swift module on disk, we were scanning all module search paths if they contain the module we are searching for. In a setup where each module is contained in its own framework search path, this scaled quadratically with the number of modules being imported. E.g. a setup with 100 modules being imported form 100 module search paths could cause on the order of 10,000 checks of `FileSystem::exists`. While these checks are fairly fast (~10µs), they add up to ~100ms.
To improve this, perform a first scan of all module search paths and list the files they contain. From this, create a lookup map that maps filenames to the search paths they can be found in. E.g. for
```
searchPath1/
Module1.framework
searchPath2/
Module1.framework
Module2.swiftmodule
```
we create the following lookup table
```
Module1.framework -> [searchPath1, searchPath2]
Module2.swiftmodule -> [searchPath2]
```
This cleans up 90 instances of this warning and reduces the build spew
when building on Linux. This helps identify actual issues when
building which can get lost in the stream of warning messages. It also
helps restore the ability to build the compiler with gcc.
This commit adds a new frontend flag that applies debug path prefixing to the
paths serialized in swiftmodule files. This makes it possible to use swiftmodule
files that have been built on different machines by applying the inverse map
when debugging, in a similar fashion to source path prefixing.
The inverse mapping in LLDB will be handled in a follow up PR.
Second pass at #39138
Tests updated to handle windows path separators.
This reverts commit f5aa95b381.
This commit adds a function to remap the clang arguments passed
during compilation. This is intented to be shared across the
Swift compiler and LLDB to apply path remapping for debug info
paths.
Mangling can fail, usually because the Node structure has been built
incorrectly or because something isn't supported with the old remangler.
We shouldn't just terminate the program when that happens, particularly
if it happens because someone has passed bad data to the demangler.
rdar://79725187
