I'm investigating a stack overflow in LLVM that I see on rust-lang/rust master for a specific test when debuginfo is enabled. How can I get LLVM to be rebuilt with x.py?
I think there's some timestamp/lockfile in
build/x86_...../llvm that you can remove
rm build/x86_64-unknown-linux-gnu/llvm/llvm-finished-building did the trick, thanks @oli.
is there an option to
x.py to expose this? We may want to add one. (That or I guess people can be like me and resort to
build/ after tearing their hair out for a while.)
(That or I guess people can be like me and resort to rm -rf'ing build/ after tearing their hair out for a while.)
I do this also and feel very sad about it every time...
how exposed do you want it? have
./x.py clean always clear the
llvm-finished-building file, but also have a flag to not do that?
./x.py clean --nuclear-option
the nuclear option is to
./x.py clean --llvm then
wait, you're saying
x.py clean does clear the
ah I see
no I think we want to preserve the current behavior
like I'm wondering if doing so by default would make more sense
x.py clean --and-clean-llvm would be good
ok, then I'll have
./x.py clean also emit a message about llvm not getting cleaned
together with a suggestion for
(or at least, that would generalize to any other submodules that similarly leave products around post-clean)
clean --and-clean-llvm seems awfully wordy and repetitive
is that on purpose? :P
x.py clean --llvm is ambiguous to me
does that only clean llvm?
clean --and-llvm then
/me also thinks redundancy ain't a bad thing when it comes to a destructive options like cleaning.
like, I have my driver scripts set up to wait for five seconds if I issue the clean command
sure, waiting five seconds is annoying, right?
but you know what's more annoying? accidentally issuing a clean command
@pnkfelix yeah; I have a more YOLO approach to cleaning
admittedly part of this workflow stems from my use of Emacs compilation mode, where just hitting
g will repeat the last compile-command that was used in the buffer
so that's a case where I want a reminder "oh, used a cleaning build the previous time, didn't mean to do that again"
@pnkfelix I don't think I've ever done an accidental
clean but I do frequently do other silly things like touch a file in the compiler and incremental is a bit daft so it causes a rebuild of the compiler...
We definitely need to make incremental smarter
and/or make x.py smarter
I think making incremental smarter would help with a lot of existing problems we have
(but we also need to improve the test suite for incremental; do more fuzzing and/or randomized test generation, in tandem with trying to ramp up effort on incremental.)
@pnkfelix mmh; I've proposed to eddyb that we should add a (morally dubious) logic to incremental whereby we specifically hash post lexing so that whitespace changes, comment changes, and random saves don't cause rebuilds.
and you just suffer with incorrect spans?
@pnkfelix kinda :slight_smile:
I was thinking more: Do rebuilds (so that span's get updated), but skip stuff like type-checking if the function only had changes of the form you mentioned
well @eddyb has a principled solution for that I believe
based on ranges or something
I've definitely accidentally cleaned
maybe adding a confirm y/n option would be helpful
it's not used frequently enough that that would be annoying, I think
x.py clean --and=llvm could be more extensible, though I'm not sure what else we might want to clean
@pnkfelix @centril just to check, regarding removing the
llvm-finished-building, I think it only triggers a rebuild if one is actually needed, and only exists because cmake is slow to do that check. is that so?
@centril the principled solution is either/both of 1. relative spans (the AST contains lengths instead of absolute positions) 2. token ranges instead of character ranges
if only I had the time to do all this right away...
considering compile times are something we're trying to improve this year, it seems that it would be a good idea to prioritise things like this
(as a team, that is)
okay well there might be enough sketched out in @eddyb 's note above that I could write up a few sentences proposal for the next rustc planning meeting
@pnkfelix funny you say that...
Perhaps we could just change the user's code ourselves in some non-trivial way? Then we know it should be rebuilt, and that would simplify incremental tremendously...
I want to fix up my build system so I won't need to do
x.py clean or accidentally break build cache by switching between
x.py build and