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.
If the fix-it would remove a range that is followed by a newline and the
remaining text on the line is empty or all whitespace then remove the entire
line. This produces better results when a fix-it removes an attribute that is
written on a line by itself.
Adds every diagnostic in the legacy `no-usage` diagnostic category to a new
diagnostic group called NoUsage so that the diagnostics can participate in
diagnostic control mechanisms like `-Werror`.
Resolves rdar://160488389.
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
`-enable-experimental-feature SourceWarningControl` guards the actual *use* of `@warn` attribute, but it did not guard this logic which queries it, which is meant to be general in the absense of the attribute as well.
We are seeing some unintended compile time performance implications from this logic, so for now guard it behind the same experimental feature flag.
Related to rdar://171506799
While '-suppress-warnings' does not fit into the overall model established with command-line controls (-Werror, -Wwarning) and declaration lexical scope controls (@warn), when users specify:
```swift
@warn(DiagGroupID, as: error)
```
They are explicitly opting in to treat certain diagnostic categories as build-halting error conditions and as such they should not longer be silenced by the '-suppress-warnings' flag.
`diagnosticInfoForDiagnostic` can return null for note diagnostics when
compiling with `-suppress-notes`. Test case exercising this in the next
commit.
Introduce `limitBehaviorIfMorePermissive` as an alternative to
`limitBehavior` that merges the new limit with the previous one. This
allows for composing different conditions that would downgrade a
diagnostics in succession.
Make sure the `DiagnosticInfo` pointer we form for `&wrapped` points
to a stable address and isn't tied to its original address in
`ActiveDiagnostics`. This fixes an issue where multiple different wrapped
diagnostics under a DiagnosticTransaction would both end up with the
same diagnostic message.
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.
We already have -suppress-warnings and -suppress-remarks; this patch
adds support for suppressing notes too. Doing so is useful for -verify
tests where we don't really care about the emitted notes.
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.
This means we now either produce a bare ErrorType, or an ErrorType
with a generic parameter original type for a generic parameter hole.
We ought to further consolidate this logic by sinking the generic
parameter original type replacement into `simplifyType` itself, but
I'm leaving that for a future patch since it affects completion
results and I want to try keep this close to NFC.
When emitting statement diagnostics for `if #available` queries, diagnose the
availability of the decls representing the referenced availability domains.
Among other things, this checks that the domains are sufficiently visible to be
used in the containing function body context.
Lift the limitation of a single active diagnostic, which was a pretty
easy-to-hit footgun. We now maintain an array of active in-flight
diagnostics, which gets flushed once all them have ended.
The ASTPrinter may kick requests that may emit diagnostics, make sure
we don't attempt to recursively print the decl since that would lead
to infinite recursion when diagnosing the cycle.
Split out the state mutation into a new `updateFor`
function that we call for diagnostic emission, allowing
`DiagnosticTransaction::hasErrors` to query the behavior without
mutating any state.
The was never invoked because inaccessibility due to SPI protection level is
always diagnosed before missing imports are diagnosed. The functionality could
therefore not be tested and should be removed.
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.
Michael Gottesman
Artem Chikin
Allan Shortlidge
Henrik G. Olsson
Anthony Latsis
Alexis Laferrière
Hamish Knight
John Hui
Doug Gregor