This is an archive of the discontinued LLVM Phabricator instance.

[tooling] Implement determinsitic ordering of CompilationDatabasePlugins
AcceptedPublic

Authored by njames93 on Nov 12 2020, 6:45 AM.

Details

Reviewers
klimek
nridge
Summary

Right now plugins appear to be registed in an undefined order based on what the linker decides to link in first.
This is undesireable as if there are multiple potential databases in a directory we can't specify which one should be treated as the defacto.

To address this there is a virtual getPriority method in the CompilationDatabasePlugin.
Plugins will then be sorted based on that(lowest first) and then search for a CompilationDatabase in the specified directory.

JSON database will now load first before Fixed database but there is plenty of room to insert plugins that would take priority over JSON, like ninja or make files.

Addresses https://github.com/clangd/clangd/issues/578

Diff Detail

Event Timeline

njames93 created this revision.Nov 12 2020, 6:45 AM
njames93 requested review of this revision.Nov 12 2020, 6:45 AM

Thanks for working on this!

clang/lib/Tooling/CompilationDatabase.cpp
73

A side effect of this change is that every plugin will get instantiated, not just the ones for which we attempt a load.

Perhaps we should store a pointer to the entry in the vector here, and instantiate() in the second loop below?

njames93 added inline comments.Nov 12 2020, 6:19 PM
clang/lib/Tooling/CompilationDatabase.cpp
73

The original setup was to instantiate every plugin until we find one that is able to load from the directory.
As for your proposed solution, that wouldn't work as we can't get the priority without instantiating the plugin.
The current registry system also doesn't lend itself nicely.
I'm not too familiar, but it could be possible to specialise SimpleRegistryEntry for CompilationDatabasePlugin.

nridge accepted this revision.Nov 12 2020, 6:45 PM

Not sure if I'm authorized to approve changes to libTooling, but this LGTM!

clang/lib/Tooling/CompilationDatabase.cpp
73

that wouldn't work as we can't get the priority without instantiating the plugin

Right, of course, I overlooked that.

Anyways, it looks like instantiating the plugin just calls its constructor and the constructors of both existing plugins are no-ops, so it shouldn't be a concern.

This revision is now accepted and ready to land.Nov 12 2020, 6:45 PM

I'm hesitant to land this right away, want to see what happens with D91454 and its related mailing list. In my mind thats a much nicer way to fix this issue.