Auto --query-driver

[sam-mccall]

Lots of people seem to need --query-driver and have trouble understanding how/when to use it.
We also have people expecting it to work in situations where it won't. Can we automate some of this?

If:

• the compile command has an absolute argv0
• we get missing-include diagnostics
• the missing include is spelled with an angle bracket (or some stdlib heuristic)

Then:

• prompt the user for permission to query the driver (window/showMessagePrompt)
• add it to the whitelist and invalidate the cache
• tell the user how to make it permanent (window/showMessage)

Not sure if we'll get to this soon, but it's a fun idea... @kadircet

[kadircet]

Yes I totally agree on making this smoother via window/showMessageRequest and permanent per-project via config stuff, rather than through command-line options (well, we can even take the liberty of updating/creating the config ourselves!!!).

I believe the conditions you mentioned are definitely the cases that users want this to automagically work. I would even go one step further and relax the first condition to argv0 exists and is executable.

I believe we didn't have the show message request at the time, hence we went down this path. As long as we get user consent, we should always lean towards the way easier for the user.

[cpsauer]

#654 morphed into a duplicate of this issue. Definitely think there's a need here.

The main point raised (x2) there but not mentioned here: Query driver being default off may well not really provide the security benefit anticipated. For example, in VSCode, one could just set the flag in the Project/.vscode/settings.json and invoke it on startup. (Discussion evolved after I'd raised just turning the query driver on by default.)

Coincidentally, just noticed that a missing --query-driver is currently breaking Google's Bazel<->IntelliJ/Android Studio integration. Was able to spot that thanks to Sam's great explanations!

[cpsauer]

A new vscode update I happened to see: There's now a popup when you open a directory, asking if you trust the code to execute files ("workspace trust")

[cpsauer]

For anyone reading, looking to get query-driver to run automatically:
You can now just set --query-driver=** (e.g. in VSCode workspace settings) and have it always run by default.

[i-ky]

You can now just set --query-driver=/**/* (e.g. in VSCode workspace settings) and have it always run by default.

You have to mention that it isn't very secure.

[cpsauer]

I mean, no more or less secure in the VSCode case, right, since the flag can be specified in a settings file in the project directory--all gated behind a trust prompt? (As above/linked).

More generally, presumably they're going to run the driver anyway to build the code and (in most cases) to work around the header flag issues. Seems worth it to me to have things work out of the box! We need --query-driver pretty often over on the Bazel-adapter side of things to pierce wrapper scripts. Though obviously super happy if there's a better solution.

[i-ky]

A new vscode update I happened to see: There's now a popup when you open a directory, asking if you trust the code to execute files ("workspace trust")

clangd/vscode-clangd#318 also talks about "workspace trust" feature.

[jlmxyz]

there could be a simple approach : if the executable match a *gcc *clangd *cc *c++ ... and so on (there aren't a lot of compilers, intel, gcc, clang... and anyway, you have to adapt to compiler specificities like -dM -E to get builtin defines, even if compilers tends to be more and more interchangeable) then treat it as the corresponding compiler (*gcc -> gcc...)

and if you want to add safety :

• prevent execute program into source tree,
• verify that the executable outside a source tree is a known workable compiler (by building a simple program) before adding it to a safe list...