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.
An objcImpl bug previously caused `@_hasStorage` to be emitted inside some extensions in module interfaces. An earlier commit in this PR created an error for this, but for backwards compatibility, it would actually be better to simply ignore the attribute in module interfaces. Modify TypeCheckStorage to emit a warning, not an error, in this situation.
Additionally, modify the module interface loader to show warnings when you verify a module interface, but not for other module interface uses (like compiling or importing one). The assumption here is that if you’re verifying a module interface, you’re either the author of the module that created it or you’re investigating a problem with it, and in either case you’d like to be told about minor defects in case they’re related.
Fixes rdar://144811653 thoroughly.
With '-sdk-module-cache-path', Swift textual interfaces found in the SDK will be built into a separate SDK-specific module cache.
Clang modules are not yet affected by this change, pending addition of the required API.
For build systems that already generate these files, it makes sense to include the aliases so that the map file serves as a comprehensive index of how the module inputs are referenced.
* Include `DeclContext` of the node where possible
* Add 'default-with-decl-contexts' dump style that dumps the dect context
hierarchy in addition to the AST
* Support `-dump-parse` with `-dump-ast-format json`
When enable bridging header auto chaining, it is possible for the
compilation to have a PCH file input for the bridging header from a
binary swift module dependency. In this case, we should not report a
bridging header for current module as bridging header can be leaking out
through swiftinterface file.
To fully distinguish the PCH files passed in through different
situation, here are the situations:
* If no chaining is used, only `-import-objc-header` option is used and
it can be used to pass either a header file or a PCH file depending if
GeneratePCH job is requested or not.
* If chaining is enabled, `-import-objc-header` is only used to pass the
header file and `-import-pch` is used to pass PCH file. Chaining mode
requires PCH generation if bridging header is used.
rdar://144623388
This commit makes a number of adjustments to how the diagnostic verifier handles source buffers and source locations. Specifically:
• Files named by `-verify-additional-file` are read as late as possible so that if some other component of the compiler has already loaded the file, even in some exotic way (e.g. ClangImporter’s source buffer mirroring), it will use the same buffer.
• Expectation source locations now ignore virtual files and other trickery; they are based on the source buffer and physical location in the file.
Hopefully this will make `-verify-additional-file` work better on Windows. As an unintended side effect, it also changes how expectations work in tests that use `#sourceLocation()`.
This flag is unsafe since the compiler does not verify that the resulting
public interface will compile with the module import removed. The modern
alternative to this flag is `@_spiOnly import`. Since the flag is no longer
used by any projects it should be removed.
Resolves rdar://134351088.
Add ability to automatically chaining the bridging headers discovered from all
dependencies module when doing swift caching build. This will eliminate all
implicit bridging header imports from the build and make the bridging header
importing behavior much more reliable, while keep the compatibility at maximum.
For example, if the current module A depends on module B and C, and both B and
C are binary modules that uses bridging header, when building module A,
dependency scanner will construct a new header that chains three bridging
headers together with the option to build a PCH from it. This will make all
importing errors more obvious while improving the performance.
Checking each module dependency info if it is up-to-date with respect to when the cache contents were serialized in a prior scan.
- Add a timestamp field to the serialization format for the dependency scanner cache
- Add a flag "-validate-prior-dependency-scan-cache" which, when combined with "-load-dependency-scan-cache" will have the scanner prune dependencies from the deserialized cache which have inputs that are newer than the prior scan itself
With the above in-place, the scan otherwise proceeds as-is, getting cache hits for entries still valid since the prior scan.
This only takes the existing AST information and writes it as JSON
instead of S-expressions. Since many of these fields are stringified,
they're not ideal for the kind of analysis clients of the JSON format
would want to do. A future commit will update these values to use a
more structured representation.
Diagnostics may be emitted while parsing command line arguments. This implies
that the options which affect how diagnostics are emitted and presented need to
be parsed first.
Diagnostics are suppressed when parsing swiftinterface files, since the
warnings emitted from compiling the swiftinterface of a dependency would just
be a nuisance. It follows that warnings generated when parsing the arguments in
a swiftinterface file should also be suppressed, but that wasn't happening
because the diagnostic engine of the main compile was used for parsing. Pass
the diagnostic engine of the compiler subinstance instead, and proactively
suppress warnings before parsing begins.
Resolves rdar://142814164.
When Swift passes search paths to clang, it does so directly into the HeaderSearch. That means that those paths get ordered inconsistently compared to the equivalent clang flag, and causes inconsistencies when building clang modules with clang and with Swift. Instead of touching the HeaderSearch directly, pass Swift search paths as driver flags, just do them after the -Xcc ones.
Swift doesn't have a way to pass a search path to clang as -isystem, only as -I which usually isn't the right flag. Add an -Isystem Swift flag so that those paths can be passed to clang as -isystem.
rdar://93951328
CAS needs to determine if an output is needed very early (when computing supplementary outputs) in the pipeline so we can do caching and replays.
Resolves: rdar://141850408
There were two cache replay code exists, one for cache replay from
swift-frontend, the other for replay using C API from libSwiftScan. It
is easy to forget to update one copy when new specialized cache replay
logic is added for some output kinds. Now unify the replay logics to a
single location to avoid confusion. This is a rewrite of the existing
logic and NFCI.
Duplicate module names on search paths produces an error, but
providing duplicate module names in a Swift explicit module map
file does not, instead the first entry will be chosen. Modify
the module map parser to error on duplicated module names as well.
The symbol graph output from a module can contain an arbitrary number of
files, depending on what extensions it contains, so cache a list of
symbol graph files with their base name and contents so that they can be
replayed.
rdar://140286819
CAS support in compiler relies on supplementary paths to decide the mapping between input and output files. Therefore, we
have to compute the paths of the module ObjC trace files in this canonical place to have CAS support for
this newly added ObjC message trace files.
It is unsound to expose `package` declarations in textual interfaces without a
package identity for them to belong to so we should not offer this flag.
Resolves rdar://139361524.
This patch adds support for serialization and deserialization of
debug scopes.
Debug scopes are serialized in post order and enablement is
controlled through the experimental-serialize-debug-info flag which
is turned off by default. Functions only referred to by these debug
scopes are deserialized as zombie functions directly.
