This feature is essentially self-migrating, but fit it into the
migration flow by marking it as migratable, adding
`-strict-memory-safety:migrate`, and introducing a test.
The following warnings get emitted every time we build the compiler libraries
that are implemented in Swift:
```
<unknown>:0: warning: ignoring -allow-non-resilient-access (overriden by -compile-module-from-interface or -typecheck-module-from-interface)
<unknown>:0: warning: ignoring -package-cmo (requires -allow-non-resilient-access)
<unknown>:0: warning: ignoring -allow-non-resilient-access (overriden by -compile-module-from-interface or -typecheck-module-from-interface)
<unknown>:0: warning: ignoring -package-cmo (requires -allow-non-resilient-access)
```
These warnings are generated because `-allow-non-resilient-access` and
`-package-cmo` are being passed in with `-Xfrontend` and are therefore copied
into the interface verification jobs, even though they don't apply. Suppress
the warnings under these circumstances; they aren't going to help anyone
understand a problem, so they're just spam.
Resolves rdar://151616909.
After removing the CASFS implementation for clang modules, there is no
need to capture clang extra file that sets up the VFS for the clang
modules since all content imported by ClangImporter is dependency
scanned and available via include-tree. This saves more ClangImporter
instance when caching is enabled.
Update the test to check that clang content found via `-Xcc` VFS options
can currently work without capture the headermaps and vfs overlays.
This is important to get diagnostics for errors which are located in imported modules.
Such errors can sometimes only be detected when building the client module, because the error can be in a generic function which is specialized in the client module.
rdar://151162353
Using IncludeTree::FileList to concat the include tree file systems that
are passed on the command-line. This significantly reduce the
command-line size, and also makes the cache key computation a lot
faster.
rdar://148752988
-nostdimport and -nostdlibimport only remove the toolchain and usr/lib/swift search paths, and they leave the framework search paths intact. That makes it impossible to get a fully custom SDK environment. Make their behavior match clang's -nostdinc/-nostdlibinc behavior: treat framework and non-framework paths the same. In other words, -nostdinc removes *all* compiler provided search paths, and -nostdlibinc removes *all* SDK search paths.
Rename SkipRuntimeLibraryImportPaths to SkipAllImportPaths, and ExcludeSDKPathsFromRuntimeLibraryImportPaths to SkipSDKImportPaths to reflect their updated behavior.
Move the DarwinImplicitFrameworkSearchPaths handling from SearchPathOptions to CompilerInvocation, where RuntimeLibraryImportPaths is managed. Rename it to just ImplicitFrameworkSearchPaths, and filter for Darwin when it's set up so that all of the clients don't have to do Darwin filtering themselves later.
rdar://150557632
Previously we would insert StringRefs that reference the keys in the
map, but that breaks if the invocation ever gets copied. Switch to
`std::string`.
rdar://148130166
With `ARCMigrate` and `arcmt-test` removed from clang in
https://github.com/llvm/llvm-project/pull/119269 and the new code
migration experience under way (see
https://github.com/swiftlang/swift-evolution/pull/2673), these options
are no longer relevant nor known to be in use. They were introduced
long ago to support fix-it application in Xcode.
For now, turn them into a no-op and emit a obsoletion warning.
Improve diagnostics message for swift caching build by trying to emit
the diagnostics early when there is more context to differentiate the
different kind of problems.
After the improvement, CAS Error should be more closer to when there is
functional problem with the CAS, rather than mixing in other kinds of
problem (like scanning dependency failures) when operating with a CAS.
rdar://145676736
The diagnostics formatter from swift-syntax previously only handled
fully-formed diagnostics anchored at a particular syntax node.
Therefore, the compiler would fall back to the existing LLVM-based
diagnostic formatter for diagnostics that had no source location.
Adopt new API in the swift-syntax diagnostics formatter that renders a
diagnostic message without requiring source location information, so
that we consistently use the swift-syntax formatter when it is
selected (which is the default).
It has indirect effects on the accessors, so it shouldn’t matter, but we can defensively redirect the query to the API counterpart anyway.
This was the last `InferredInABIAttr` attribute, so we can now remove all of the infrastructure involved in supporting attribute inference.
The "featues" part was never actually implemented and Swift Driver
is replying on information about arguments, so instead of removing
this mode, let's scope it down to "arguments" to be deprecated in
the future.
This is a replacement for `-emit-supported-features` that prints
all of the upcoming/experimental features supported by the compiler
with some additional meta information in JSON format to stdout.
We decided that using a magic typealias to set the executor factory was better
than using a compiler option. Remove the `-executor-factory` option, and replace
by looking up the `DefaultExecutorFactory` type, first in the main module, and
then if that fails in Concurrency.
rdar://149058236
Currently, the macro plugin options are included as cache key and the
absolute path of the plugin executable and library will affect cache
hit, even the plugin itself is identical.
Using the new option `-resolved-plugin-validation` flag, the macro
plugin paths are remapped just like the other paths during dependency
scanning. `swift-frontend` will unmap to its original path during the
compilation, make sure the content hasn't changed, and load the plugin.
It also hands few other corner cases for macro plugins:
* Make sure the plugin options in the swift module is prefix mapped.
* Make sure the remarks of the macro loading is not cached, as the
mesasge includes the absolute path of the plugin, and is not
cacheable.
rdar://148465899
When serializing `@available` attributes, if the attribute applies to a custom
domain include enough information to deserialize the reference to that domain.
Resolves rdar://138441265.
For now the semantics provided by `@extensible` keyword on per-enum
basis. We might return this as an upcoming feature in the future with
a way to opt-out.
When generating an objc header from the swift module when a bridging
header is used, make sure to use the original bridging header, not
the chained bridging header. This also avoids incorrectly generated a
header include when no actual bridging header is used, just a chained
bridging header that is coming from a dependency.
rdar://148446465
We're not ready to start emitting warnings when type-checking modules from
interface. It is causing performance regressions and spurious diagnostics to be
emitted.
Reverts a small part of https://github.com/swiftlang/swift/pull/80360.
Resolves rdar://148257136.
Print diagnostic groups as part of the LLVM printer in the same manner as the
Swift one does, always. Make `-print-diagnostic-groups` an inert option, since we
always print diagnostic group names with the `[#GroupName]` syntax.
As part of this, we no longer render the diagnostic group name as part
of the diagnostic *text*, instead leaving it up to the diagnostic
renderer to handle the category appropriately. Update all of the tests
that were depending on `-print-diagnostic-groups` putting it into the
text to instead use the `{{documentation-file=<file name>}}`
diagnostic verification syntax.
We've been converging the implementations of educational notes and
diagnostic groups, where both provide category information in
diagnostics (e.g., `[#StrictMemorySafety]`) and corresponding
short-form documentation files. The diagnostic group model is more
useful in a few ways:
* It provides warnings-as-errors control for warnings in the group
* It is easier to associate a diagnostic with a group with
GROUPED_ERROR/GROUPED_WARNING than it is to have a separate diagnostic
ID -> mapping.
* It is easier to see our progress on diagnostic-group coverage
* It provides an easy name to use for diagnostic purposes.
Collapse the educational-notes infrastructure into diagnostic groups,
migrating all of the existing educational notes into new groups.
Simplify the code paths that dealt with multiple educational notes to
have a single, possibly-missing "category documentation URL", which is
how we're treating this.
We're moving over to a model where we provide direct links to educational notes /
diagnostic group notes whenever relevant. Rendering the Markdown from these
files to the terminal is less relevant with this approach, so remove it from the
compiler.
Rather than pointing at a Markdown file in the toolchain directory by default,
which won't render well immediately for most users, point at the sources on
GitHub, which will render it properly and will still work from (e.g.)
CI systems where the toolchain content might not be accessible.
Toolchain-aware diagnostic renders can look in the installed toolchain
location (share/doc/swift/diagnostics) for the markdown files for that
specific version of the markdown files.
