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.
Unfortunately, Unsafe*Pointer types do not support non-escapable
pointees so we do not really have anything to map these types to at the
moment. Previously, importing such code resulted in crashes.
rdar://145800679
This simplifies the code to emit availabilty diagnostics and ensures that they
display domain names consistently. While updating existing diagnostics, improve
consistency along other dimensions as well.
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
Since the diagnostic is not going to be emitted counting it in
`Swift6Errors` statistics is going to be confusing to the users.
Resolves: https://github.com/swiftlang/swift/issues/79291
Resolves: rdar://145341605
Checking whether a declaration is in a `.swiftinterface` is a very common query
that is made somewhat awkward because declarations are not always in source
files. To make these checks more ergonomic, expose a convenience on
DeclContext.
As an example, use this for the "`@preconcurrency` on import has no
effect" warning, which is not yet working correctly. This disables it
by default but leaves it in place for our testing.
Anthony Latsis
Alexis Laferrière
Hamish Knight
Artem Chikin
John Hui
Allan Shortlidge
Doug Gregor
Gabor Horvath
Pavel Yaskevich
Slava Pestov