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.
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.
Improve the version/flags extract from interface file by moving away
from using Regex and limiting the search to the beginning of the file.
Switch away from Regex will give 5-10% improvement in time and
instruction counts, and limiting the search lines can save a lot of time
if the swiftinterface is large. For example, the extract time for Swift
stdlib is 10x faster after the patch.
Current strategey for limiting the line to search is by only parsing the
first comment block.
This change refactors the top-level dependency scanning flow to follow the following procedure:
Scan():
1. From the source target under scan, query all imported module identifiers for a *Swift* module. Leave unresolved identifiers unresolved. Proceed transitively to build a *Swift* module dependency graph.
2. Take every unresolved import identifier in the graph from (1) and, assuming that it must be a Clang module, dispatch all of them to be queried in-parallel by the scanner's worker pool.
3. Resolve bridging header Clang module dpendencies
4. Resolve all Swift overlay dependencies, relying on all Clang modules collected in (2) and (3)
5. For the source target under scan, use all of the above discovered module dependencies to resolve all cross-import overlay dependencies
It might be unexpected to future users that `-swift-compiler-version`
would produce a version aligned to .swiftinterface instead of one used
to build the .swiftmodule file. To avoid this possible confusion, let's
scope down the version to `-interface-compiler-version` flag and
`SWIFT_INTERFACE_COMPILER_VERSION` option in the module.
Based on feedback in PR https://github.com/swiftlang/swift/pull/69460, enabling indexing for synthesized decls because they are usable by users and make sense to appear in the indexstore.
Sets `synthesized` on some additional decls:
- derived `hashInto(...)`
- Objc properties and methods derived from Objc protocols
https://github.com/apple/swift/issues/67446
If swiftinterface doesn't have `-swift-compiler-version` flag
it means that it was generated with an older version of the
Swift compiler. In such cases it would be incorrect to use
"current" compiler version because the field is intended to
indicate the compiler the swiftinterface was built with.
Use the `%target-swift-5.1-abi-triple` substitution to compile the tests for
deployment to the minimum OS versions required for use of opaque types, instead
of disabling availability checking.
Use the `%target-swift-5.1-abi-triple` substitution to compile the tests for
deployment to the minimum OS versions required for use of _Concurrency APIs,
instead of disabling availability checking.
When setting up the ModuleInterfaceChecker, prefer using the module
cache path from command-line invocation `-module-cache-path` before
falling back to clang options.
Usually those two yield the same result, except for LLDB under direct
cc1 argument mode and explicit module build. Under such mode, the cc1
option for module cache path will be stripped since the output PCMs are
explicit passed as output. When LLDB attempted to do an implicit module
compilation for the swift interface, it will not be able to locate the
module cache path from cc1 arguments. On the other hand, the module
cache option has already be inherited by the sub-instance so it can just
directly be located there.
rdar://137610484
When the frontend option `-abi-comments-in-module-interface` is provided
during interface printing, the printed interface will contain
additional comments that provide the mangled names for public symbols.
This is an experiment in seeing how much information we can
meaningfully extract from a printed Swift interface for the purpose of
bridging with other languages.
A couple of tests are expecting merge-modules behaviour,
add `-no-emit-module-separately` in those cases to
ensure that merge modules is used in both the old
and new driver.
