This is an archive of the discontinued LLVM Phabricator instance.

[clangd] clangd --check: standalone diagnosis of common problems
ClosedPublic

Authored by sammccall on Sep 25 2020, 1:45 PM.

Details

Summary

This is a tool to simply parse a file as clangd would, and run some
common features (code actions, go-to-definition, hover) in an attempt to
trigger or reproduce crashes, error diagnostics, etc.

This is easier and more predictable than loading the file in clangd, because:

  • there's no editor/plugin variation to worry about
  • there's no accidental variation of user behavior or other extraneous requests
  • we trigger features at every token, rather than guessing
  • everything is synchronoous, logs are easier to reason about
  • it's easier to (get users to) capture logs when running on the command-line

This is a fairly lightweight variant of this idea.
We could do a lot more with it, and maybe we should.
But I can't in the near future, and experience will tell us if we made
the right tradeoffs and if it's worth investing further.

Diff Detail

Event Timeline

sammccall created this revision.Sep 25 2020, 1:45 PM
sammccall requested review of this revision.Sep 25 2020, 1:45 PM
nridge added a subscriber: nridge.Sep 27 2020, 1:03 PM

thanks! this mostly looks good, as discussed offline I believe having an infra that we can improve over time is better than not having anything until we've got the "perfect" solution.

i just got a couple of questions about some pieces, and some nits.

clang-tools-extra/clangd/tool/Check.cpp
57

put into anon namespace?

87

i agree, this would help identifying the case of "clangd binary has been copied to some place without the necessary lib directory".

but i think we should check for the final -resource-dir in the compile command below. as user's compile flags can override whatever default clangd comes up with.

95

we don't have any custom fallback commands, what's the point of printing this always?

125

IIRC, option providers don't really log anything about success/failure of parsing the config file. what's the point of having this exactly?

126

it is clear that we've crashed while parsing compile commands if we don't see cc1 args are in the output. so maybe drop this one?

131

maybe we should also note that this doesn't reflect the final result. as we turn off pchs or dependency file outputting related flags afterwards.

137

this seems ... surprising :D but I also don't have suggestion for a better place.

202

maybe we could print errors if the following has no results for "identifiers" ?

214

nit: maybe make this a free function and return ErrCount ?

clang-tools-extra/clangd/tool/ClangdMain.cpp
52

why not have this in Check.h ?

833

nit: static_cast<int>(Err..)

maybe do the same for line 846 while here. (line 872 already does that)

sammccall updated this revision to Diff 295290.Sep 30 2020, 8:01 AM
sammccall marked 6 inline comments as done.

address (some of) comments

clang-tools-extra/clangd/tool/Check.cpp
87

Moved FIXME to the right place.

125

This is needed in order to run the correct clang-tidy checks.

126

I don't think that's clear - you can find it out by reading the code, but I expect people to be running this who aren't reading the code. (They won't be able to work out all the details, but they tend to be interested in the broad strokes of what's going on).

So generally I've tried to include log statements before each major step.

131

Sure, and we also run clang-tidy, and fiddle with the preamble, and skip function bodies...

I think a disclaimer that "running clangd is not equivalent to running clang <cc1-args>" would be somewhat confusing, as I'm not sure that's a thing that anyone would expect to be true.

I expect the cc1 args to be useless to anyone not familiar with clangd internals, but they're kind of important to include. Reworded the log message a bit, is this enough?

202

There are lots of ways go-to-def can yield no results (e.g. macros, #ifdef-'d sections, templated code we can't resolve)

clang-tools-extra/clangd/tool/ClangdMain.cpp
52

A header seems a bit out of place in tool/ and it doesn't seem necessary, being one function with a simple signature and no unit tests.

We'll get a linker error if we ever get this wrong, right?

kadircet accepted this revision.Oct 1 2020, 1:47 AM

thanks LGTM!

clang-tools-extra/clangd/tool/Check.cpp
108

already done in the else statement.

125

ah sorry, i forgot Inputs was a member

131

SG, and actually thinking again, we are only making changes in the positive direction for clangd. i.e. there shouldn't be an instance in which this cc1 works, but clangd fails.

clang-tools-extra/clangd/tool/ClangdMain.cpp
52

yeah, it just felt uncommon, i don't think we can mess this up.

This revision is now accepted and ready to land.Oct 1 2020, 1:47 AM
This revision was landed with ongoing or failed builds.Oct 1 2020, 6:48 AM
This revision was automatically updated to reflect the committed changes.
sammccall marked an inline comment as done.

Thanks, I think this fails whenever compile_commands.json doesn't exist in the tree or under build.
(Which of course it does in my local checkout...). Reverted, probably need to rename/copy the test file.

rsmith added a subscriber: rsmith.Oct 1 2020, 2:09 PM
rsmith added inline comments.
clang-tools-extra/clangd/test/check.test
2

This test implicitly parses a source file that #includes standard library headers, and fails if those headers aren't available; this causes the test to fail in some build environments. Would it be possible to make this test work in freestanding environments?

hoy added a subscriber: hoy.Oct 1 2020, 3:46 PM
hoy added inline comments.
clang-tools-extra/clangd/tool/Check.cpp
244

Hi, I'm seeing an error with this "tweak: ExpandAutoType ==> FAIL: Could not deduce type for 'auto' type". It's probably due to that the std string header was not available when running check.test, thus the test failed. Is it expected that the header is available when test is run? Thanks.

Sorry @rsmith @hoy, I've replaced the test with one without such dependencies in bc18d8d9b705d31a94c51900c8b18e4feaf9c7fb.

hoy added a comment.Oct 2 2020, 9:27 AM

Sorry @rsmith @hoy, I've replaced the test with one without such dependencies in bc18d8d9b705d31a94c51900c8b18e4feaf9c7fb.

Thanks for the quick turnaround!