Keep track of all of the type parameters and archetypes that are captured
by a local function or closure. Use that information to diagnose cases
where a non-Sendable metatype crosses an isolation boundary.
* 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`
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.
Parsing for `-enable-upcoming-feature` and `-enable-experimental-feature` is
lenient by default because some projects need to be compatible with multiple
language versions and compiler toolchains simultaneously, and strict
diagnostics would be a nuisance. On the other hand, though, it would be useful
to get feedback from the compiler when you attempt to enable a feature that
doesn't exist. This change splits the difference by introducing new diagnostics
for potential feature enablement misconfigurations but leaves those diagnostics
ignored by default. Projects that wish to use them can specify `-Wwarning
StrictLanguageFeatures`.
`libTestPlugin.dylib` dynamic library was previously linking against
`libLLVMSupport.a`, which is already linked into the Swift compiler
binary. This caused multiple conflicting definitions of `LLVMSupport`
lib symbols, leading to ODR violations. This issue has been addressed
by linking against `libLLVMSupport` via `-hidden-lLLVMSupport` flag,
ensuring `libLLVMSupport` symbols remain hidden within the plugin,
preventing conflicts with those in the Swift compiler.
Fixes: https://github.com/swiftlang/swift/issues/77771.
Instead, each scan's 'ModuleDependenciesCache' will hold all of the data corresponding to discovered module dependencies.
The initial design presumed the possibility of sharing a global scanning cache amongs different scanner invocations, possibly even different concurrent scanner invocations.
This change also deprecates two libSwiftScan entry-points: 'swiftscan_scanner_cache_load' and 'swiftscan_scanner_cache_serialize'. They never ended up getting used, and since this code has been largely stale, we are confident they have not otherwise had users, and they do not fit with this design.
A follow-up change will re-introduce moduele dependency cache serialization on a per-query basis and bring the binary format up-to-date.
Type annotations for instruction operands are omitted, e.g.
```
%3 = struct $S(%1, %2)
```
Operand types are redundant anyway and were only used for sanity checking in the SIL parser.
But: operand types _are_ printed if the definition of the operand value was not printed yet.
This happens:
* if the block with the definition appears after the block where the operand's instruction is located
* if a block or instruction is printed in isolation, e.g. in a debugger
The old behavior can be restored with `-Xllvm -sil-print-types`.
This option is added to many existing test files which check for operand types in their check-lines.
To allow feature build settings to be composed more flexibly, allow an
`-enable-upcoming-feature` flag to be overridden by a
`-disable-upcoming-feature` flag. Whichever comes last on the command line
takes effect. Provide the same functionality for `-enable-experimental-feature`
as well.
Resolves rdar://126283879.
Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
If an upcoming feature was enabled by passing it via `-enable-experimental-feature`,
downgrade the `already enabled` diagnostic to a warning.
Resolves rdar://139087679.
This is something that I have wanted to add for a while and have never had the
need to. I need it now to fix a bug in the bots where I am forced to use IRGen
output to test ThunkLowering which causes platform level differences to show up
in the FileCheck output. With this, I can just emit the actual lowered SIL
output and just test it at that level. There are other cases like this where we
are unable to test lowered SIL so we use IRGen creating this brittleness.
Hopefully this stops this problem from showing up in the future.
rdar://138845396
Also, dump the module map paths when `-Xfrontend -dump-clang-diagnostics` is
passed in, both so we can check that manually and in these tests, and fix
another Frontend test to be more specific now that this other output trips it up.
For batch compile jobs, it's helpful to see which files are considered primary
and that was the original reason why filelist contents were printed in compiler
crash stack dumps. However, for whole module compile jobs, the contents of the
filelist is uninteresting (it's just all the files in the module) and can be
hundreds or thousands of lines long so it often causes important information to
be trimmed from stack dumps received in reproducers.
During the lifecycle of a feature, it may start as an experimental feature and
then graduate to become an upcoming feature. To preserve compatibility with
projects that adopted the feature when it was experimental,
`-enable-experimental-feature` ought to be able to enable upcoming features,
too.
Since projects may use `-enable-experimental-feature` for compatibility with an
older toolchain that does not have the feature as an upcoming feature, there is
no warning when the flag is used to enable an upcoming feature.
Note that if the semantics of a feature change when it graduates from
experimental to upcoming, then the feature must be renamed so that projects
using the experimental feature have an opportunity opt-in to the new semantics
of the upcoming feature.
Resolves rdar://134276783.
The legacy `module.map` spelling of module map files was deprecated by llvm/llvm-project#75142 and clang expects to remove support for them in the future. Switch all tests to use the supported spelling.
Fixes rdar://128431478.
The refactoring in #68760 accidentally caused us to
start parsing skipped function bodies if they have
parameters, as the local discriminator request kicks
parsing through `getBody()`. Cherry-pick part of
47ff9568db749def08007b64a5425789cb514ac3 which was
never landed, ensuring we don't call `getBody` for
a skipped function body.
This is meant to be a minimal low-risk change that
fixes the issue in question, restoring the behavior
we had in 5.10. Fixing the parser skipping
behavior for `#sourceLocation` will be done in
a follow-up. We also ought to see if there's a
better way we can enforce that skipped function
bodies don't end up getting parsed, for now I've
added a test.
rdar://131726797
