This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Add diagnostic augmentation hook to Modules
AbandonedPublic

Authored by kadircet on Feb 26 2021, 7:19 AM.

Details

Reviewers
sammccall
Summary

Depends on D96245

Diff Detail

Event Timeline

kadircet created this revision.Feb 26 2021, 7:19 AM
kadircet requested review of this revision.Feb 26 2021, 7:19 AM
sammccall added inline comments.Mar 3 2021, 9:49 PM
clang-tools-extra/clangd/Module.h
97

This seems too specialized to me - maybe we want to observe diagnostics only, or mutate some other property of them.

Consider just passing in the (mutable) clangd::Diag, and returning void? Maybe call it handleDiagnostic or so

Maybe also the clang::Diagnostic if you really need it.

98

random thoughts about how this gets called... (definitely not for now though!)

There are other things we might want to do while building ASTs.
e.g. *generate* diagnostics (maybe IWYU or clang-tidy can be modules)
At that point maybe we want something like

virtual unique_ptr<ParseASTHooks> Module::parseAST() { return nullptr; } // threadsafe
class ParseASTHooks { // implementations need not be threadsafe
  virtual void sawDiagnostic(clangd::Diag &D);
  virtual void finish(ParsedAST&);
};

That way it's easier to reason about call sequences. (and it eliminates the problem of calling an empty virtual method on each module for each diagnostic)

kadircet added inline comments.Mar 4 2021, 1:59 AM
clang-tools-extra/clangd/Module.h
97

passing in clangd::Diag and mutating it sounds pretty neat, thanks!

I do think it is also useful to pass clang::Diagnostic though, as it usually contains extra semantic information that might be used to generate a fix.
For example in case of missing module deps:

  • it knows about the particular include/import that triggered the diagnostic
  • name of the current module.

The former can be inferred from diagnostic range and reading the source code (we'll need to pass in sourcemanager somehow though, to ensure we read the same version of the file), and the latter can be inferred by looking at the compile commands (or implementations can query the build system with TUs name etc.). But this is one particular case, it might tie our hands when we want to generate fixes that require deeper semantic analysis (like type info) in the future. So i think we should really be passing clang::Diagnostic too.

So I'll update this to take in a read-only clang::Diagnostic, Level and a mutable clangd::Diag, does that SG?

98

SG indeed, I'd be happy to do that in a follow-up change.

Though this might still have the problem of calling an empty virtual method with each diag, for example if a module doesn't do anything per-diagnostic but only does something on finish, but it definitely limits the scope.

Is this entirely obsoleted by the approach in D98499?

Herald added a project: Restricted Project. · View Herald TranscriptMar 15 2021, 11:33 AM
kadircet abandoned this revision.Mar 23 2021, 4:30 AM

Is this entirely obsoleted by the approach in D98499?

yes it is!