Skip to content
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

On needing to rebuild project target after running :refresh_compile_commands #147

Closed
brtdylan opened this issue Dec 12, 2023 · 8 comments
Closed

Comments

@brtdylan
Copy link

Hey there, just wanting to see if I can gain some understanding about an issue I'm seeing while using this amazing tool with our (fairly complex) codebase

For a while I was seeing spurious in-line compile errors in my editor after generating compile commands. I was going a little mad trying to figure out the root cause, and I realized that if I rebuild a target in our codebase (not yet clear to me if it needs to be the target for which I'm editing src, or any target within our project) after running :refresh_compile_command, everything becomes happy again. So the magic workflow for me seems to be: build our repo to produce any generated files, run :refresh_compile_commands, build something else in our repo (cached, fast).

My best guess as to why that does the trick is that by re-building a relevant target in our repo, the bazel symlink paths are re-established to align with the valid paths that match what the generated compile commands expect. I'm sort of waving my hands though, and my bazel-fu isn't strong enough to understand the full picture here, so I wanted to see if this sounds like anything y'all have come across // sounds expected?

Anyway, I'm super happy everything's working again with this tool, it's truly a life saver! Thank you for continuing to develop and support it 👏

@ashpil
Copy link

ashpil commented Dec 14, 2023

Experiencing this as well, seems related to #140.

@cpsauer
Copy link
Contributor

cpsauer commented Dec 14, 2023

Hey, Dylan. Good to hear from you again.

I'm surprised--and would like this tool to not have that behavior if we can make it so. To make sure I'm understanding correctly: Everything's fine, with generated files generated, but then when you re-run this tool, header searching breaks until you run a build again. Is that right?

I wish I knew what was wrong off the top of my head, but I don't; I haven't run into this in our codebase, and on a quick test, I'm seeing generated files hold up across runs of the tool. I totally believe you about the problem and everything, but that means I'm going to need your help tracking it down further. Any pattern in the headers that can't be found? Are the paths to them indeed getting removed from the filesystem on build, and if so what are they? Are they _virtual_includes? There aren't any bazel-bins in your compile_commands.json, are there? (That's the only thing that should change between runs, but we shouldn't be referencing it.) Maybe also comment back your OS, just in case that's relevant. Any other ideas about what might be going on?

Delighted to hear this tool is otherwise so useful to you guys. Still love the seal photo :)
Chris

@cpsauer
Copy link
Contributor

cpsauer commented Dec 14, 2023

Wrote that without having seen your crossref, yet, Andrei, or having read the updates over there. Dylan, could you check that yours are indeed all virtual includes (the bane of this tool lol), and if so, subscribe to #140 and close this so we're all tracking it and working together there?

@cpsauer
Copy link
Contributor

cpsauer commented Dec 14, 2023

If it is, we'll likely have it resolved soon. I put up a PR over at bazelbuild/bazel#20540 that should fix.

Any amount you'd like to chime in over there to encourage merging would be much appreciated :)

@brtdylan
Copy link
Author

Hi Chris, Thanks for following up! And thanks Andrei for pointing out that issue, I believe that's what's at play here as well. The compile errors seem to be mostly around generated protobuf and flatbuffer code, and I'm seeing that many protobuf and flatbuffer files are within a _virtual_includes dir in the compile_commands.json (though not the generated headers themselves, seems more like protobuf src dirs?). I will close this one and follow along there. Awesome to see you were able to root cause already + have a fix up 🥳 I'll close this issue as a dupe of #140 and will try to test it on our repo and follow up there / on your PR

And if you're local to the Bay Area, and haven't done it before, winter time is a great time to see the elephant seals & seal pups around Pt Reyes as they come in to the beaches for pupping season 🦭 : )

@brtdylan brtdylan closed this as not planned Won't fix, can't repro, duplicate, stale Dec 18, 2023
@cpsauer
Copy link
Contributor

cpsauer commented Dec 19, 2023

Likewise! Hopefully they merge it in soon. Thanks for being great.

I am indeed local and have fond childhood memories of going to see :) I also just think seals are cute.

(I'm around Stanford most of the time; if you're ever around and want to say hi, drop me a line. Could be fun to meet up. Just shoot me an email at cpsauer at cs dot stanford dot edu if so.)

@cpsauer
Copy link
Contributor

cpsauer commented Dec 19, 2023

And thanks for the support :)

@cpsauer
Copy link
Contributor

cpsauer commented Jan 20, 2024

The fix has made it into the bazel mainline!

Thanks for helping track this down and get it in--should be released as part of Bazel 7.1 and the next rolling release!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants