This commit adds new compiler options -no-warning-as-error/-warning-as-error which allows users to specify behavior for exact warnings and warning groups.
This enables one to use varying prefixes when checking diagnostics with the
DiagnosticVerifier. So for instance, I can make a test work both with and
without send-non-sendable enabled by adding additional prefixes. As an example:
```swift
// RUN: %target-swift-frontend ... -verify-additional-prefix no-sns-
// RUN: %target-swift-frontend ... -verify-additional-prefix sns-
let x = ... // expected-error {{This is always checked no matter what prefixes I added}}
let y = ... // expected-no-sns-error {{This is only checked if send non sendable is disabled}}
let z = ... // expected-sns-error {{This is only checked if send non sendable is enabled}}
let w = ... // expected-no-sns-error {{This is checked for a specific error when sns is disabled...}}
// expected-sns-error @-1 {{and for a different error when sns is enabled}}
```
rdar://114643840
We're going to move toward the new swift-syntax formatter. Use it for
the "swift" diagnostic style instead of the experimental formatter
written in C++.
There are some tests for the experimental formatter in C++ that test
precise formatting of diagnostics. I've disabled them in the same
places where the new swift-syntax formatter is enabled, for now. We
may choose to remove them entirely, because swift-syntax itself is
where the specific format is defined, and has those same kinds of
tests already.
Add frontend flag `-emit-macro-expansion-files diagnostics` to emit any
macro expansion buffers referenced by diagnostics into files in a
temporary directory. This makes debugging type-checking failures in
macro expansions far easier, because you can see them after the
compiler process has exited.
The SwiftDiagnostics module within swift-syntax has a diagnostic
pretty-printer that does a nice rendering of the source code with
diagnostics placed inside gaps between the code lines.
Introduce another `-diagnostic-style` argument, `swift-syntax`,
to bridge from the pretty-printed C++ diagnostics over to the
swift-syntax diagnostics engine.
Introduces a concept of a dependency scanning action context hash, which is used to select an instance of a global dependency scanning cache which gets re-used across dependency scanning actions.
This change adds a frontend flag, -verify-additional-file, which can be used to pass extra files directly to the diagnostic verifier. These files are not otherwise considered to be Swift source files; they are not compiled or even properly parsed.
This feature can be used to verify diagnostics emitted in non-source files, such as in module interfaces or header files.
This default formatting style remains the same "LLVM style". "Swift style"
is what was previously enabled via -enable-experimental-diagnostic-formatting
* [Diagnostics] Turn educational notes on-by-default
* [Diagnostics] Only include educational notes in printed output if -print-educational-notes is passed
* Make -print-educational-notes a driver option
* [Diagnostics] Issue a printed remark if educational notes are available, but disabled
* [docs] Update educational notes documentation and add a contributing guide
* [Diagnostics] Cleanup PrintingDiagnosticConsumer handling of edu notes
* Revert "[Diagnostics] Issue a printed remark if educational notes are available, but disabled"
For now, don't notify users if edu notes are available but disabled. This decision can be reevaluated later.
* [Diagnostics] Experimental diagnostic printing updates
This new style directly annotates small snippets of code with
error messages, highlights and fix-its. It also uses color more
effectively to highlight important segments.
* [Diagnostics] Stage educational notes and experimental formatting behind separate frontend flags
educational notes -> -enable-educational-notes
formatting -> -enable-experimental-diagnostic-formatting
* [Diagnostics] Refactor expensive line lookups in diag formatting
* [Diagnostics] Refactor some PrintingDiagnosticConsumer code into a flush method
* [Diag-Experimental-Formatting] Custom formatting for Xcode editor placeholders
* [Diag-Experimental-Formatting] Better and more consistent textual description of fix its
* [Diags-Experimental-Formatting] Handle lines with tab characters correctly when rendering highlights and messages
Tabs are converted to 2 spaces for display purposes.
* [Diag-Experimental-Formatting] Refactor byte-to-column mapping for efficiency
* [Diag-Experimental-Formatting] Fix line number indent calculation
* [Diag-Experimental-Formatting] Include indicators of insertions and deletions in the highlight line
Inserts are underlined by green '+' chars, deletions by red '-' chars.
* [Diag-Experimental-Formatting] Change color of indicator arrow for non-ASCII anchored messages
* [Diag-experimental-formatting] Make tests less sensitive to line numbering
* [Diag-Experimental-Formatting] Update tests to allow windows path separators
* [Diag-Experimental-Formatting] Bug fixes for the integrated REPL
Educational notes are small pieces of documentation which explain a concept
relevant to some diagnostic message. If -enable-descriptive-diagnostics is
passed, they will be printed after a diagnostic message if available.
Educational notes can be found at /usr/share/doc/diagnostics in a
toolchain, and are associated with specific compiler diagnostics in
EducationalNotes.def.
This flag will feature-gate work on producing more descriptive diagnostic messages.
It will remain a hidden frontend option until these improvements are ready to ship.
This flag adds diagnostic names to the end of their messages, e.g. 'error: cannot convert value of type '[Any]' to specified type '[Int]' [cannot_convert_initializer_value]'. It's intended to be used for debugging purposes when working on the compiler.
- Add CompilerInvocation::getPCHHash
This will be used when creating a unique filename for a persistent
precompiled bridging header.
- Automatically generate and use a precompiled briding header
When we're given both -import-objc-header and -pch-output-dir
arguments, we will try to:
- Validate what we think the PCH filename should be for the bridging
header, based on the Swift PCH hash and the clang module hash.
- If we're successful, we'll just use it.
- If it's out of date or something else is wrong, we'll try to
emit it.
- This gives us a single filename which we can `stat` to check for the
validity of our code completion cache, which is keyed off of module
name, module filename, and module file age.
- Cache code completion results from imported modules
If we just have a single .PCH file imported, we can use that file as
part of the key used to cache declarations in a module. Because
multiple files can contribute to the __ObjC module, we've always given
it the phony filename "<imports>", which never exists, so `stat`-ing it
always fails and we never cache declarations in it.
This is extremely problematic for projects with huge bridging headers.
In the case where we have a single PCH import, this can bring warm code
completion times down to about 500ms from over 2-3s, so it can provide a
nice performance win for IDEs.
- Add a new test that performs two code-completion requests with a bridging header.
- Add some -pch-output-dir flags to existing SourceKit tests that import a bridging
header.
rdar://problem/31198982
Enables Chris's auto-apply-fixes mode for -verify: if an expected-*
annotation has the wrong message, or if the expected fix-its are
incorrect, this option will **edit the original file** to update them.
This is a tool for compiler developers only; it doesn't affect
normal diagnostic printing or normal fix-its.
- Added missing ifdef guard in PointerIntEnum header
- Consistent naming convention for ifdef guards
- Consistent 'end namespace swift'
- Consistent single EOL at end of header files
Exposes the global warning suppression and treatment as errors
functionality to the Swift driver. Introduces the flags
"-suppress-warnings" and "-warnings-as-errors". Test case include.
Previously, the frontend detected that its output was being piped into the
driver and buffered, and decided that that wasn't a color-friendly output
stream. Now, the driver passes -color-diagnostics to the frontend to force
color output if the driver itself is in a color-output context.
<rdar://problem/16697713>
Swift SVN r18506
Added a new DiagnosticOptions class to swiftBasic, and added a DiagnosticOptions member to CompilerInvocation.
Added a static ParseDiagnosticArgs function to parse diagnostic-related arguments.
Added -verify to FrontendOptions.td, and added support for parsing -verify in ParseDiagnosticArgs.
Updated frontend_main() to enable and trigger the DiagnosticVerifier when -verify is passed.
Swift SVN r11318
