New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
File Compiled Multiple Times: Intersect Suggestions, Union Errors? #681
Comments
This has long been on my list of "things I'd like my ideal IDE to be able to do" :) I've yet to use an IDE that could do this. |
Phew, well, Xcode does for Apple platforms. It's nice! But imagine that for all platforms. Is Xcode clangd-based? Must be, right? |
May I also suggest accepting multiple compile_commands.json files? In a realistic scenario, these files would be obtained by multiple
Is this feature new in Xcode? It used to only show the warnings for the single selected target platform. |
Note that there's also the case where a file is compiled multiple times across different compilation databases. |
Hi all,
This is a bit of a thorny one, but raises some interesting general questions, I think.
An individual C++ file might be specified several times in a compile_commands.json if, for example, it's cross-compiled for multiple platforms. The spec seems to explicitly consider this case.
Clangd instead seems to pick just one entry per file arbitrarily and use that. (Correct me if I'm wrong.) This means, that, for example, a C++ file might get suggestions for macOS APIs, even if it's meant to be cross-platform. This isn't terrible--you get suggestions for all the actions you might want to take and all the errors are real errors--but you do get some erroneous suggestions and miss some real errors.
The "right" thing to do conceptually, I think, would be to take all the commands used to compile a file. Suggestions would be the intersection of the suggestions for each compilation listed. Errors would be the union of the errors for each compilation.
There are some rough edges for the above around #ifdefs, for example. And you might have to merge similar commands for performance reasons. But in general, the command merging strategy seems more fraught. (Consider, for example, the case where different versions of a header with the same name are accessible through different include paths.)
Thoughts? Is this a case clangd would be interested in handling? Is there a cleaner way of thinking about it that I'm missing?
Thanks so much for considering,
Chris
(Perhaps debatable whether this is more feature or bug given the compile_commands spec, but I'll label increased generality as a feature.)
The text was updated successfully, but these errors were encountered: