The `git grep` command fails if the repository has a branch named `test`.
Inserting a `--` in the git command line makes it clear that `test` is the directory and not the branch
We sometimes don't have the information in the modulemaps whether a
module requires ObjC or not. This info is useful for reverse interop.
This PR introduces a frontend flag to have a comma separated list of
modules that we should import as if they had "requires ObjC" in their
modulemaps.
Attempt to use `git grep` instead of `grep`. This might help reduce the
cost of this test. Currently, on Windows, this test takes ~350s, placing
it 2nd in the slowest tests on Windows.
Instead of first invoking `grep` to get a list of files with matches,
and then invoking it again on each file to find lines with matches,
invoke it once on the entire test suite to get a list of paths and lines
with matches, and parse that output into a dictionary that maps file
paths to lists of lines.
This further reduces run time from ~2.5s to ~1s.
* Account for variable number of spaces.
* Match strings like '-enable-upcoming-feature\'. We want to complain
about these because the script cannot get the job done when the option
and argument are on different lines.
The capture group will match '' in these cases.
* The set of files that enable features and the set of files that
require features are expected to have a very small, if any,
difference. Don't compute and check each set separately.
* Find RUN and REQUIRES lines in a file in one go.
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`.
The new `DECL_ATTR_FEATURE_REQUIREMENT` macro in DeclAttr.def can be used to declare that an attribute should only be available when a related language feature is enabled.
Effects:
• `#if hasAttribute(someAttr)` will return `false` unless the required feature is enabled.
• Code completion will not include the attribute unless the required feature is enabled.
• `TypeChecker::checkDeclAttributes()` diagnoses non-implicit uses of the attribute.
Add this mechanism and use it to tie @abi to the ABIAttribute feature. Also design tests for it.
Sometimes features are removed from `Features.def`, but they are not
removed from the test files. The compiler ignores every feature that
does not exist. This leads to removed features still being tested, and
with the introduction of #76740, `REQUIRED:`.
Modify the code that generates the active feature set for testing to
also generate the set of existing features, and pass this list of
existing features to the verifier script. If a feature is trying to be
activated and does not exist, the verifier will warn the user.
- `SwiftParser` feature was renamed `ParserASTGen`, but some tests were
using both spellings. Remove the mentions of `SwiftParser` in the
tests.
- `ImportObjcForwardDeclarations` was spelled with upper case `C` in
a couple of tests. Fix it so the matching is easier.
- `TransferringArgsAndResults` was an experimental feature that was
removed.
- Ignore the usage of inexisting feature in `swift-export-as.swift`
because it seems to be what the test is actually testing.
- Ignore the test `availability_define.swift` because it tests the
pseudo-feature `AvailabilityMacro=` which is not part of
`Features.def`.
When a feature is removed from `Features.def` or when a test removes all
usages of `-enable-experimental/upcoming-feature` keeping the
`REQUIRES:` lines around is probably a mistake. Warn about possibly
missing flags if a `REQUIRES:` is found referencing a feature without
the equivalent `-enable-*-feature` in a `RUN:` line.
The test will look for other tests using `RUN:` lines that use
experimental or upcoming features and will check that the tests also are
checking with the right `REQUIRES:` lines for the used features. This
should avoid new tests being introduced without the right `REQUIRES` and
should avoid breaking the toolchain in less tested configurations.
