ClangD - Dropped Diagnostic Outside of main file.

Hi, I hope you dont mind me contacting you directly.

I don’t mind at all, but I’m out on parental leave so can’t give this the attention it deserves. Adding the dev list.
I am integrating ClangD with an open source IDE. I have come across a minor issue, but its most likely my inexperience with clangd.

So if I have a file that includes another file and that file has an include that cant be found, the diagnostics for that missing include get dropped.

How would I be able to indicate to the users that there is a missing include file, or get hold of the dropped diagnostic without the user having to open that file first?

So if we’re dropping the “foo.h was not found” diagnostic when the missing file is directly included by the active file, this is just a bug we should fix. (I seem to recall this might be happening, at least in some situations).

For diagnostics that occur in other files, we do currently just drop them, but we should do something smarter. (This includes transitive includes like → foo.h → bar.h where bar.h is missing, but also if foo.h has a syntax error).

I’d suggest we synthesize a diagnostic at the #include site that says something like:

Included file had errors:

foo.h:21: Missing ‘;’
foo.h:43: No such member ‘qux’, did you mean ‘quux’

What do you think?
(And anyone on clangd-dev want to take this up before I get back to work?)

Any hints or advice is greatly appreciated.

Many Thanks

Dan - working on AvalonStudio

Hadn’t heard about AvalonStudio, will check it out!
Please hit up clangd-dev if we can help!

Hi Dan, Sam,

Synthesizing the diagnostics sounds good!
Also agree we should summarize all diags coming from the include in a single message to avoid potentially reporting a hundred diags at the same line.
Please also note that we can’t catch any errors in function bodies, since we skip those. That’s one of the reasons we don’t report diags from other files now - we just can’t do it reliably.

Missing files are actually the most common source of inconsistencies in the current file, though, reporting them is definitely the right thing to do!
Dan, would you be interested in coming up with a patch to fix this? We’re always happy to get new contributions.

Agree, having some errors is probably more useful than having none.

I could try, but someone would have to tell me where to look in the code, im so new to clang, llvm, etc I might be a little out of my depth :blush:

If this is a small change I could probably tackle it, any pointers ?

It should be a pretty small and localized change.

Clang has an API for consuming diagnostics and our consumer code is in Diagnostics.cpp, most of the work is done in the HandleDiagnostic function.
The code there shouldn’t be too hard to follow, and feel free to contact us if you run into any problems.

The LLVM’s Getting Started Guide is a good place to start if you haven’t done any LLVM development before.

пн, 13 авг. 2018 г. в 19:41, Dan Walmsley via clangd-dev <>: