llvm::cl::opt flags are compiled out in non-asserts builds, making these
debug flags unavailable in an important category of use cases — debugging
a release compiler in lldb. By promoting them to Swift frontend flags stored
in DiagnosticOptions/SILOptions, they are available in all build
configurations.
The three existing flags are migrated:
-diagnostics-assert-on-error
-diagnostics-assert-on-warning
-sil-region-isolation-assert-on-unknown-pattern
(backing field renamed to AbortOnUnknownRegionIsolationPatternError)
A new flag is added:
-diagnostics-assert-on-group <group>
Traps when any diagnostic belonging to the named group is emitted,
allowing targeted breakpoints on a single diagnostic group rather than
all errors or all warnings.
The assert-on-{error,warning,group} flags are intentionally kept separate
from the normal diagnostic suppression/escalation machinery so that they
remain useful while other diagnostics are also being emitted.
Tests are added for all four flags.
Default to use new swift-driver to run lit tests as legacy swift driver
is deprecated for a long time. The lit tests for legacy drivers are also
disable when running new swift-driver.
Tests that relies on legacy swift driver (for example, tests merge
module) can be enabled on conditions `legacy_swift_driver`. Fix and
split up some existing tests that relies on legacy driver.
When a diagnostic belongs to a group that has a parent group (`GROUP_LINK` in `DiagnosticGroups.def`), display the full inheritance chain in the diagnostic output, including documentation hyperlinks and footnotes for each.
For example, a diagnostic in `ExistentialType` (child of `PerformanceHints`) now renders as:
```
warning: ... [#PerformanceHints::ExistentialType]
```
Groups without parents continue to display as before (`[#DeprecatedDeclaration]`).
Resolves rdar://170805800
Adding the 'ALLOW_RETRIES` to
`diagnostics/bad-generated-filenames.swift`
There is an occasional assertion failure in `c-index-test` that I
suspect is related to recent changes in the FileManager related to
filenames:
```
Assertion failed: (DirInfo &&
"The directory of a virtual file should already be in the cache.")
```
This is happening in `getVirtualFileRef` in
`llvm-project/clang/lib/Basic/FileManager.cpp` on line 419.
https://github.com/swiftlang/llvm-project/blob/cb7976f735018074787ce9b86040c081bb568b93/clang/lib/Basic/FileManager.cpp#L418-L419
Re-enabling the diagnostics/bad-generated-filenames.swift test.
I don't see what caused this test to be x-failed in the first place and
is causing CI failures due to unexpectedly passing. If it is crashing in
the future, I will need a core file or some way to reproduce it at
the bare minimum.
This brings this control in line with other diagnostic controls we have which operate on a per-group level.
'DefaultIgnoreWarnings' diagnostic group option applies to all warnings belonging to a certain diagnostic group.
The inheritance rules are:
- Marking a diagnostic group as 'DefaultIgnoreWarnings' means warnings belonging to this group will not be emitted by-default
- Warnings belonging to sub-groups of this group will also not be emitted by-default
- Enabling a 'DefaultIgnoreWarnings' group (with '-Werror','-Wwarning', etc.) means warnings belonging to this group will be emitted.
- Warnings belonging to sub-groups of this group will also be emitted.
- Warnings belonging to super-groups of this group will not be affected.
Filter out any duplicate notes to help cut down on the noise for
request cycle diagnostics. Some of the note locations here still aren't
great, but this at least stops us from repeating them for each
intermediate request.
With `ARCMigrate` and `arcmt-test` removed from clang in
https://github.com/llvm/llvm-project/pull/119269 and the new code
migration experience under way (see
https://github.com/swiftlang/swift-evolution/pull/2673), these options
are no longer relevant nor known to be in use. They were introduced
long ago to support fix-it application in Xcode.
For now, turn them into a no-op and emit a obsoletion warning.
Print diagnostic groups as part of the LLVM printer in the same manner as the
Swift one does, always. Make `-print-diagnostic-groups` an inert option, since we
always print diagnostic group names with the `[#GroupName]` syntax.
As part of this, we no longer render the diagnostic group name as part
of the diagnostic *text*, instead leaving it up to the diagnostic
renderer to handle the category appropriately. Update all of the tests
that were depending on `-print-diagnostic-groups` putting it into the
text to instead use the `{{documentation-file=<file name>}}`
diagnostic verification syntax.
We've been converging the implementations of educational notes and
diagnostic groups, where both provide category information in
diagnostics (e.g., `[#StrictMemorySafety]`) and corresponding
short-form documentation files. The diagnostic group model is more
useful in a few ways:
* It provides warnings-as-errors control for warnings in the group
* It is easier to associate a diagnostic with a group with
GROUPED_ERROR/GROUPED_WARNING than it is to have a separate diagnostic
ID -> mapping.
* It is easier to see our progress on diagnostic-group coverage
* It provides an easy name to use for diagnostic purposes.
Collapse the educational-notes infrastructure into diagnostic groups,
migrating all of the existing educational notes into new groups.
Simplify the code paths that dealt with multiple educational notes to
have a single, possibly-missing "category documentation URL", which is
how we're treating this.
We're moving over to a model where we provide direct links to educational notes /
diagnostic group notes whenever relevant. Rendering the Markdown from these
files to the terminal is less relevant with this approach, so remove it from the
compiler.
Emit the category documentation URL into serialized diagnostics as part of
the existing RECORD_CATEGORY, using the form
<category name>@<category URL>
and keeping the existing "category name length" field referring to the
length of the category name itself (up to the @). There is a corresponding
update to libclang to process such category names correctly and add
API, but it isn't strictly necessary: readers that use the category
name length field correctly will see no behavior change, whereas
readers that ignore it will merely see the extra `@<category URL>`.
This is a step toward staging out our (mis)use of the "flags" field as
the place to stash educational note and diagnostic group documentation
URLs.
When printing diagnostics, category names are printed as [#<category-name>]
at the end of a diagnostic. For all of the category names that are mentioned
in this manner, print "footnotes" at the end of compilation providing
documentation references to each category, e.g.,
[#deprecated]: <http://example.com/deprecated>
[#StrictMemorySafety]: <http://example.com/memory-safety>
Right now, these point into the markdown files in the installed toolchain,
same as the URLs behind references. That is subject to change in the future.
The serialized diagnostic format has some extra fields that we can
adopt for diagnostic groups. Specifically:
* Category: store the diagnostic group name here
* Flags: extend the hack used by educational notes of placing Markdown file paths here
While here, also sort and deduplicate output entries, and stop having
the Python script try to
The Python script is still messing up the files in some cases, but
I haven't tracked it down. Instead, I have a small Swift program
that does the same thing more easily.
Adjust the valid position checking and special handle EOF position.
If the requested location is at EOF, use the last token, but still
emit the diagnostics at the specificied location.
rdar://138426038
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.
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.
These tests are using FileCheck to check the result of diagnostic
formatting in ways that don't match the new formatter. Force the old
formatter or, where possible, generalize so that they match both
formatters.
When a file defining an API is included in two modules, clients calling
that API may get an error about the ambiguity on the duplicated API.
That error is not very helpful when it takes into account the
swiftsourceinfo data and points to the source file instead of the
module. In such a case the notes point twice to the same file and line
of code.
Improve this diagnostic by appending the module name to the notes when a
candidate is found outside of the module.
rdar://116255141
Use flag record (currently unused) to emit semi-colon separated
list of paths to educational notes associated with a diagnostic.
Resolves: rdar://118993780
The serialized diagnostics reader has one very specific limitation it
places on filenames: they must not end in `/`, because that makes them
look like a directory. This is not documented, and the diagnostics
reader will unceremoniously crash when trying to read such a file.
While the reader should be fixed to at least fail gracefully in such
cases, Swift also shouldn't generate such filenames. Right now, they
can be generated when referencing an entity named `/` that is
synthesized or comes from a module. When we encounter such file names,
append `_operator` to avoid the problem.
Fixes rdar://118217560.
Show the same error for both decls and imports when using the package
access level and no package name is set. Also brings up this check to
run once on decls and avoid repeated diagnostics.
We'll be using the new swift-syntax diagnostic formatter in the near
future, as it is nearly available on all host platforms. So, remove
the C++ formatter that did source-line annotation, falling back to the
"LLVM" style when swift-syntax is not compiled in.
`module.map` as a module map name has been discouraged since 2014, and
Clang will soon warn on its usage. This patch renames all instances of
`module.map` in the Swift tests to `module.modulemap` in preparation
for this change to Clang.
rdar://106123303
Michael Gottesman
Allan Shortlidge
Steven Wu
Artem Chikin
Evan Wilde
Pavel Yaskevich
Jamie
Hamish Knight
Anthony Latsis
Doug Gregor
Rintaro Ishizaki
Dmitrii Galimzianov
Pavel Yaskevich
Alexis Laferrière
Slava Pestov
Michael Spencer
Ellie Shin