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.
Add a new type of diagnostic transaction, CompoundDiagnosticTransaction.
The first diagnostic emitted inside the transaction will become the parent of the subsequent notes.
DiagnosticConsumers may opt in to consuming these child notes alongside the parent
diagnostic, or they can continue to consider them seperately.
Moved PrintingDiagnosticConsumer and a couple of diagnostics to the new
system as a proof of concept.
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
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.
If diagnostics are produced as part of a transaction, let's copy
strings associated with arguments into a separate long(er) term
storage which is going to be cleaned up when diagnostic is actually
emit to the consumers.
Use the "nearest source location" information on a request to map it
to a particular source buffer, then use that information in the
GraphViz dependency graphs so we can see cross-file dependencies more
clearly.
Currently only works for types that are /just/ a 'some' type, not in a
nested position. Also won't show them for opaque types with different
requirements, to avoid noise when it's not strictly necessary. This
does mean that 'some P' vs. 'some P & Q' won't get the origin part.
Part of rdar://problem/50346954
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Remove the unnecessary use of the positional arguments in the diagnostic
formatting. This is not portable as it is a SUS extension and the Microsoft C
runtime does not support this extension.
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.
LLVM r334399 (and related Clang changes) moved clang::VersionTuple to
llvm::VersionTuple. Update Swift to match.
Patch by Jason Molenda.
rdar://problem/41025046
By formalizing ReferenceOwnership as a diagnostic argument kind, we get
less boilerplate, better type safety, better output consistency, and
last but not least: future proofing.
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.
Adjust the definition of some diagnostics that are already called with
DeclBaseNames so that the implicit conversion from DeclBaseName to
Identifier is no longer needed.
Adjust the call side of diagnostics which don't have to deal with
special names to pass an Identifier to the diagnostic.
If we won't show the diagnostics anyway, don't go to the trouble of
performing the typo-corrections, which can be expensive. This is really
helpful if there is a module import failure, which may cause many names
to fail to resolve and would otherwise trigger typo-correction.
rdar://problem/29003372
