* Implement 'getDiagnosticSeverity()' and 'getDiagnosticMessage()' on
'CodeCompletionResult'
* Differentiate 'RedundantImportIndirect' from 'RedundantImport'
* Make non-Sendable check respects '-warn-concurrency'
rdar://76129658
These were duplicated in 11 different files, and as they've gotten more
complex a few inconsistencies have snuck in. Sharing them should make future
changes easier and less bug-prone.
These are defined with macros like errors/warnings/notes, and
make use of format strings and diagnostic arguments. The intent
is to leverage diagnostic arguments in the future to disambiguate
ambiguously spelled types.
Ported a few miscellaneous fix-its to the new system
Before this patch, we used to define tooling-specific diagnostics. With adding more
checking logics, we found this mechanism hard to extend. This patch
eliminates the home-made diagnostics model to use the one from compiler, which provides
several benefits: less boiler-templates, better integration with DiagnosticConsumer,
and easy ordering of detected issues.
This allows reporting successful and unsuccessful optimizations similar to
clang/llvm.
This first patch adds support for the
options -Rpass=<pass-name-regex> -Rpass-missed=<pass-name-regex>. These allow
reporting successful/unsuccessful optimization on the compiler output for passes
specified by the regex. I've also added one missed and one passed remark type
to the inliner to test the infrastructure.
Clang also has the option of collecting these records in an external YAML data
file. This will be added in a later patch.
A few notes:
* The goal is to use this facility for both user-lever "performance" warnings
and expert-level performance analysis. There will probably be a flag in the
future differentiating the verbosity.
* The intent is match clang/llvm as much as it makes sense. On the other hand I
did make some changes. Unlike in llvm, the emitter is not a pass which
simplifies things. Also the remark class hierarchy is greatly simplified since
we don't derive from DiagnosticInfo. We also don't derive from Diagnostic to
support the streaming API for arbitrary named-value pairs.
* Currently function names are printed mangled which should be fixed.
Diagnostic categories are entirely unused and arguably useless as
implemented, as they merely denote the sub-component of the
compiler.
As far as categorizing warnings are concerned, I'm abandoning the
effort for now, as the utility is marginal and Swift and the Swift
compiler are probalby not ready for these to be nailed down. For the
sake of cleanliness, the CATEGORY field is also stripped from
WARNINGS.
If there's a need for automatic identifying of compiler sub-components
for diagnstics in the future, there are better ways to do this.
NFC
We're not mapping source locations over correctly yet, so the file name
where an error occurs gets shoved into the diagnostic text, but that's
fine for now.
This also silences the "module 'Blah' not found" error coming from the
importer whenever Swift itself can be responsible for importing the module.
Still to do: if we can't build a Clang module, we shouldn't report that
error and then say it can't be found.
<rdar://problem/14509389>
Swift SVN r18230
Added DiagnosticsDriver.def and DiagnosticsDriver.h for driver-only diagnostics.
(Diagnostics which are shared with the frontend remain in
DiagnosticsFrontend.{def,h}.)
Added a DiagnosticEngine& to Compilation, so that it can emit diagnostics for
events which occur while performing Jobs.
Replaced all of the locations where we were manually printing error messages to
emitting real diagnostics, adding diagnostics if necessary.
Updated Driver::buildCompilation() so that it fails early if any errors were
encountered.
Updated test/Driver/actions.swift to pass a -module-name for multi-input tests.
Swift SVN r13175
Thanks to the way we've set up our diagnostics engine, there's not actually
a reason for /everything/ to get rebuilt when /one/ diagnostic changes.
I've split them up into five categories for now: Parse, Sema, SIL, IRGen,
and Frontend, plus a set of "Common" diagnostics that are used in multiple
areas of the compiler. We can massage this later.
No functionality change, but should speed up compile times!
Swift SVN r12438
