This is an archive of the discontinued LLVM Phabricator instance.

[Tooling] add a Heuristic field indicating that a CompileCommand was guessed.
ClosedPublic

Authored by sammccall on Apr 3 2019, 4:56 AM.

Details

Summary

Use cases:

  • a tool that dumps the heuristic used for each header in a project can be used to evaluate changes to the heuristic
  • we want to expose this information to users in clangd as it affects accuracy/reliability of editor features
  • express interpolation tests more directly

Diff Detail

Repository
rL LLVM

Event Timeline

sammccall created this revision.Apr 3 2019, 4:56 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 3 2019, 4:56 AM

I'll leave the LGTM to Manuel. I don't have a strong opinion here, but here are some thoughts.

The approach taken seems to be the least-leaky that I can think of unless we want to change the return type of CompilationDatabase::getCompileCommand or add a new method that would explicitly be used to infer commands. Both options are rather tricky to implement.
Yet, having the new field in the CompileCommand feels wrong, especially in combination with a fact that CompilationDatabase returns a vector of compile commands rather just a single command, i.e. after this patch implementations can technically return a combination of inferred and non-inferred commands for the same file, which might force clients to think about proper prioritization and filtering commands, something I'd rather keep hidden.

ilya-biryukov accepted this revision.Apr 5 2019, 7:54 AM

LGTM, Manuel does not mind having this and the string heuristic does look like the easiest approach to convey this information in the API.

This revision is now accepted and ready to land.Apr 5 2019, 7:54 AM

Yet, having the new field in the CompileCommand feels wrong, especially in combination with a fact that CompilationDatabase returns a vector of compile commands rather just a single command, i.e. after this patch implementations can technically return a combination of inferred and non-inferred commands for the same file, which might force clients to think about proper prioritization and filtering commands, something I'd rather keep hidden.

I do think the vector<CompileCommand> return isn't ideal, though I'm not sure it's really related to this change - the CDB can return inferred and non-inferred commands today, and there's no guidance on which to pick.
(I was thinking of adding some, but different tools do different things e.g. pick first, or iterate over all, and I'm not sure which is best :-/)

This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptApr 5 2019, 8:20 AM