This is an archive of the discontinued LLVM Phabricator instance.

[diagnostics] Integrate clang -cc1as diagnostics into DiagnosticsEngine
AbandonedPublic

Authored by sanwou01 on Mar 30 2017, 9:27 AM.

Details

Summary

Add initial support for printing assembly diagnostics using the
DiagnosticsEngine infrastructure. Add support for -w (no warnings) and
-Werror (warnings are errors) and print a summary with the number of
errors and warnings. -fcolor-diagnostics handling is implemented as
well.

This patch adds a subclass to FullSourceLoc, called UnifiedSourceLoc,
which can hold an llvm-style SourceLoc and SourceMgr. This class is
responsible for the translation from the clang::FullSourceLoc API to
llvm-style operations.

With these changes in place, it will be possible to convert inline
assembly diagnostics as well.

Missing is support for ranges and hints.

Event Timeline

sanwou01 created this revision.Mar 30 2017, 9:27 AM
sanwou01 edited the summary of this revision. (Show Details)Mar 30 2017, 9:33 AM

What advantages does this have over the current way of printing diagnostics? If this is just to get -w and -Werror working, would it not be easier to pass those through to the assembler, than to send all diagnostics back through clang? We already have some flags in MCTargetOptions that should be able to to the same things -w and -Werror do.

On the other hand, if this would enable other features, like -W options to promote/suppress categories of assembler warnings, than this might allow us to avoid duplicating a lot of clang's diagnostic system in the LLVM SourceMgr. Do you have any ideas for how this could be done?

Hi Oli,

Thanks for taking a look! You're right, -w and -Werror could be implemented by passing them as MCTargetOptions flags.

This patch is indeed intended to enable -W options to promote or silence (categories of) warnings. To enable that, the first step is to be able to associate a diagnostic with an identifier. Clang defines IDs (and their warning groups) in Diagnostic*Kinds.td. The IDs need to be available where a diagnostic is raised, so a table for LLVM diagnostics (or just the enum) needs to live on the LLVM side (but they'd share encoding space with the clang enum, e.g., the clang diag enum starts where the llvm diag enum ends). It is then a matter of plumbing this ID from the point where the diagnostic gets raised, into an SMDiagnostic, and into the DiagnosticsEngine on the clang side.

Once the infrastructure is in place, the calls to Report() and friends can be updated with IDs on a case by case basis.

Thanks,
Sanne

That all sounds sensible from an assembler perspective, especially the ability to gradually move diagnostics into categories rather than having one big change that touches every assembler diag. However, I've not done much work in clang, so it would be good to get someone more familiar with the clang diagnostics/driver side of things to have a look at this too.

sanwou01 updated this revision to Diff 95548.Apr 18 2017, 3:34 AM

Rebase on top of D31709 and D32159

sanwou01 retitled this revision from [RFC] Integrate clang -cc1as diagnostics into DiagnosticsEngine to [diagnostics] Integrate clang -cc1as diagnostics into DiagnosticsEngine.Apr 18 2017, 3:40 AM
sanwou01 edited the summary of this revision. (Show Details)
sanwou01 updated this revision to Diff 95549.Apr 18 2017, 3:47 AM

Don't include the changes from D31709 and D32159 in this patch (oops).

sanwou01 abandoned this revision.Nov 7 2019, 7:07 AM