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.
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.
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()`.
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.
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.
The diagnostics engine has some code to pretty-print a declaration when
there is no source location for that declaration. The declaration is
pretty-printed into a source buffer, and a source location into that
buffer is synthesizes. This applies to synthesized declarations as well
as those imported from Swift modules (without source code) or from Clang.
Reimplement this pretty-printing for declarations as a request. In
doing so, change the manner in which we do the printing: the
diagnostics engine printed the entire enclosing type into a buffer
whose name was the module + that type. This meant that the buffer was
shared by every member of that type, but also meant that we would end
up deserializing a lot of declarations just for printing and
potentially doing a lot more work for these diagnostics.
`-mcpu` is a deprecated "alias" (unsupported) on x86 targets for
`-mtune`. Unlike `-mcpu`, `-mtune` simply tunes the code for the CPU but
does not prevent execution on other targets. In order to match the
behaviour of `-mcpu` on ARM, we must use both `-march=` and `-mtune=`.
Adjust this behaviour to allow tuning of code for non-Darwin targets.
An existing test (Frontend/skip-function-bodies.swift) was designed under the
assumption that multiple `-debug-forbid-typecheck-prefix` arguments were
already supported, and as a result the test was not actually asserting what it
was written to assert.
- Simplify the fix locator when looking for a
fix already present in a pattern match, this
avoids us emitting both a diagnostic for the
argument conversion, and for a conformance failure.
- Include tuples in the diagnostic logic where
we emit a generic "operator cannot be applied"
diagnostic, as a conformance diagnostic is
unlikely to be helpful in that case.
When emitting a diagnostic that references a declaration that does not
itself have a source location (e.g., because it was synthesized or
deserialized), the diagnostics engine pretty-prints the declaration
into a buffer so it can provide caret diagnostics pointing to that
declaration.
Start marking those buffers as "generated source buffers", so that we
emit their contents into serialized diagnostics files. This will allow
tools that make use of serialized diagnostics to also show caret
information.
The `__future__` we relied on is now, where the 3 specific things are
all included [since Python 3.0](https://docs.python.org/3/library/__future__.html):
* absolute_import
* print_function
* unicode_literals
* division
These import statements are no-ops and are no longer necessary.
1. Removes gating on -enable-experimental-concurrency.
2. Updates eff. prop tests to remove experimental flag,
and also adjusts some tests slightly to avoid things
that are still behind that flag.
- Prefer CGFloat -> Double over the other way around to avoid
ambiguities;
- Every new conversion impacts the score by factor of number of
previously applied conversions to make it possible to select
solutions that require the least such conversions.
- Prefer concrete overloads with Double <-> CGFloat conversion
over generic ones.
