If the access-level on imports proposal is accepted as written, all
imports printed in swiftinterfaces will be `public`. Whether or not we
require the explicit `public` keyword in Swift 6 mode, printing it will
have no downside. It also goes along with the mentality that
swiftinterfaces should be more explicit than implicit.
rdar://115455383
Previously, fully qualified types would be missing for global vars and
properties in `.swiftinterface` files that were emitted lazily.
Adding the test case also revealed that PatternBindingDecls needed to be
typechecked before lazy module serialization as well.
The `-experimental-skip-all-function-bodies` and
`-experimental-serialize-external-decls-only` flags are unnecessary because
this test now uses the `-typecheck` action instead of the `-emit-module`
action.
Previously, unsatisfiable conformances could be omitted from emitted
`.swiftinterface` files in lazy typechecking mode since inherited types might
be unresolved when gathering the conformances.
Adding these test cases also revealed that serialization restrictions needed to
be relaxed in order to accomodate unsatisfiable conformances.
Previously, indirect public conformances provided by conforming to an internal
protocol could be skipped in a `.swiftinterface` in lazy typechecking mode
since inherited types might not be resolved before collecting the indirect
conformances.
Previously, conformances inherited through a base class could be missed in lazy
typechecking mode if types in the inheritance clause were not already resolved.
Previously, `usesFeatureRethrowsProtocol()` could mistakenly return false in
lazy typechecking mode since the types in an inheritance clause might not have
been resolved yet.
Previously, a `.swiftinterface` emitted in lazy typechecking mode would fall
back on printing the `TypeRepr` of entries in the inheritance clause of a
declaration since inherited types could be unresolved.
Use this to define the macro location rather than the "host" dir (which
is actually for the build and not the host). Furthermore, on Windows,
the build dir is /usr/lib/swift as the host content is in the SDK.
This prepares the tests for Windows.
When `-experimental-serialize-external-decls-only` is specified, skip
serializing conformances to protocols that should be skipped to avoid
unnecessary typechecking. Also, ensure type and value witnesses are resolved
lazily during serialization by passing `true` for `useResolver`.
Resolves rdar://114799742
This allows the ModuleInterface test to attempt to build a client against the
emitted `.swiftinterface` which will help us ensure the emitted interface is
correct.
Don't print the uses of freestanding declaration macros in Swift
interfaces. Instead, print the declarations they produce, as
appropriate.
Fixes rdar://113730928.
Also, restructure the `CHECK:` lines for the `-emit-tbd` test. The number of
columns in the `.tbd` file appears to be variable, so we can't assume a layout
for the symbols in the YAML.
Type-checking patterns is not fully requestified, so the
ASTPrinter should not assume this has been filled in.
It appears sufficient to just visit the associated VarDecl,
as we do already.
Frontend options should only be printed under `swift-module-flags-ignored:`
temporarily to prevent condfails for older development compilers that are still
in use (as a rule of thumb, swiftinterfaces should be compatible with compilers
that are up to 6 months old). None of the frontend flags that are currently
categorized as "ignorable" need to be ignorable anymore.
Experimental mode for generating module interfaces without running
primary file type-checking. The idea is that the ASTPrinter triggers
requests to only do the minimum amount of type checking work
possible while printing the interface for a module's public
declarations.
These requests may emit diagnostics, but the ASTPrinter should in
theory already be robust against invalid code.
Tests that use the `%target-swift-emit-module-interface` lit substitution are
designed to test the behavior of the compiler when emitting module interfaces
for resilient libraries. It therefore makes sense to pass `-parse-as-library`
by default for these frontend invocations.
Fixes a few tests that were accidentally depending on parsing source files as
top level code.
The code of `ScanDependencies.cpp` was creating invalid JSON since #66031
because in the case of having `extraPcmArgs` and `swiftOverlayDependencies`,
but not `bridgingHeader`, a comma will not be added at the end of
`extraPcmArgs`, creating an invalid JSON file. Additionally that same PR
added a trailing comma at the end of the `swiftOverlayDependencies`, which
valid JSON does not allow, but that bug was removed in #66366.
Both problems are, however, present in the 5.9 branch, because #66936
included #66031, but not #66366.
Besides fixing the problem in `ScanDependencies.cpp` I modified every test
that uses `--scan-dependencies` to pass the produced JSON through
Python's `json.tool` in order to validate proper JSON is produced. In
most cases I was able to pipe the output of the tool into `FileCheck`,
but in some cases the validation is done by itself because the checks
depend on the exact format generated by `--scan-dependencies`. In
a couple of tests I added a call to `FileCheck` that seemed to be
missing.
Without these changes, two tests seems to be generating invalid JSON in
my machine:
- `ScanDependencies/local_cache_consistency.swift` (which outputs `Expecting ',' delimiter: line 525 column 11 (char 22799)`)
- `ScanDependencies/placholder_overlay_deps.swift`
The review of SE-0395 is down to small details at this point that won't
affect the overall shape of the API much. Rename the model in
anticipation of that.
