This test was disabled on Windows through the `MSC_VER` condition. The
failure was due to the redirection of the output which does not behave
entirely the expected way with the lit shell. Use a temporary file
instead and enable the test on Windows.
Instead, stimulate users to follow the referenced bug reporting guidelines,
which contain all the necessary information. We’d rather encourage attempts
at reducing issues before attaching Xcode projects. This is an accompaniment
to https://github.com/apple/swift-org-website/pull/158.
Introduce the `-enable-upcoming-feature X` command-line argument to
allow one to opt into features that will be enabled in an upcoming language
mode. Stage in several features this way (`ConciseMagicFile`,
`ForwardTrailingClosures`, `BareSlashRegexLiterals`).
When we encounter an input or output with an unknown extension 'TY_INVALID', still produce valid JSON specifying the type as "unknown" instead of either crashing or producing malformed JSON.
Resolves rdar://94348593
Experimental features can only be enabled in non-production (+Asserts)
builds. They can be detected with `hasFeature` in the same manner as
"future" features.
The `-enable-experimental-feature X` flag will also look for future
features by that name, so that when an experimental feature becomes an
accepted future feature, it will still be enabled in the same manner.
Switch variadic generics over to this approach, eliminating the
specific LangOption for it.
FrontendTool sets up diagnostic infrastructure early and suppresses stdout diagnostics if frontend-parseable-output is enabled. It then calls `CompilerInstance.setup` which may fail - if it fails, we exit early. But that means we have not gotten a chance to emit parseable-output.
This change moves emission of the `began` parseable message to before `CompilerInstance.setup`, and ensures that a corresponding `finished` message is emitted if the setup fails.
Resolves rdar://93187783
Generation of valid JSON output for parseable output depends on being able to determine file types of inputs and outputs of compilation tasks. FileTypes.def defines multiple file kinds with multiple '.' extensions, such as '.abi.json' or '.features.json', but existing code attempted to compute file outputs only using the trailing suffix of the path after the last '.'. This led to some files not being recognized, which led to us not being able to generate valid JSON.
Resolves rdar://92961252
Don't run the objc-arc-contract pass when disable-llvm-optzns is passed.
In pipeline setups where the swift-frontend is called twice;
- the first time to create bitcode
- the second time to generate object code from the bitcode (using
disable-llvm-optzns)
we don't want to run the objc-arc-contract pass twice.
rdar://91908312
This change removes the -emit-cxx-header option, and adds a new -emit-clang-header-path option instead. It's aliased to -emit-objc-header-path for now, but in the future, -emit-objc-header-path will alias to it. After this change Swift can start emitting a single header file that can be expose declarations to C, Objective-C, or C++. For now C++ interface is generated (for all public decls) only when -enable-cxx-interop flag is passed, but that behavior will change once attribute is supported.
You can now put `||` between two fix-its to indicate that the test succeeds if either of them is present. This is meant for situations where a fix-it might vary slightly in different subtests or test configurations.
Also fixes a bug in the diagnostic verifier where "expected-whatever" would search beyond the same line for its opening "{{", potentially finding one many lines away and giving a bad diagnostic and poor recovery behavior.
If, for instance, an error is emitted as a warning instead, the verifier now detects this and emits a single diagnostic saying that the warning was found but had the wrong kind, instead of emitting one diagnostic saying the error was missing and another saying the warning was unexpected.
In theory there are some edge cases we could handle better by doing two separate passes—one to detect exact expectation matches and remove them, another to detect near-misses and diagnose them—but in practice, I think the text + diagnostic location is likely to be unique enough to keep this from being a problem. (I would hesitate to do wrong-line diagnostics in the same pass like this, though.)
