can cargo-bisect-rustc respect the .cargo/config.toml? #284
Comments
|
It should be working. Can you share your exact |
|
Since this involves a bunch of files, let me see if I can put it into a repo for the repro. |
|
(Hmm, I am now seeing evidence that it is doing something with the config file. Namely, when I added |
|
Here's the repository I'm using for reproduction of the problem I'm seeing: https://github.com/pnkfelix/cbr-issue-284-demo When I run cargo bisect rustc, it ends up flagging a regression in nightly-2023-03-12 (and then tracks the problem down further from there). The problem is that the flagging of the regression there only happens if you are not passing the rustflags that I have requested. And I have confirmed that manually invoking transcriptThe problem with all of the above is that when I manually run the same bisector builds directly, it does respect the rustflags I've fed in via the |
|
To be clear: At this point I am forced to acknowledge that something must be happening with the So there must be some really weird interaction with the specific rustflags setting I happen to be using? It is goofy. |
|
The reason you are seeing different behavior when running manually is because you are not passing the This happens because cargo tries to share dependencies when |
|
BTW, if you need to pass rustflags to proc-macros even when [target.'x86_64-unknown-linux-gnu']
rustflags="-Clink-arg=-Wl,--no-undefined-version"
[host]
rustflags="-Clink-arg=-Wl,--no-undefined-version"And pass the |
|
Hmm, okay. I can totally understand how this arises now. I'm trying to figure out what is the best way to address overall issue here. In particular:
Here's the heart of my complaint: The usage model that I think we try to promote is: "If you're doing ... Maybe all I want here is some section of the doc where we spell out ways in which |
|
I think at least documenting it would be good. One place I forgot to mention this is in https://rust-lang.github.io/cargo-bisect-rustc/usage.html#scripting, where it should be mentioned that scripts don't need to specify It seems a little strange to me that it unconditionally sets the target, but it looks like that was done in part for cross-rs/cross#699, where |
I agree with this point. That is, we should adjust the documentation to reflect what the tool does (though that might itself change, as you outline in your second paragraph), but we cannot rely on people to read the docs. However, that does lead me to this question: Is there any verbosity level at which
I'll have to think about this. It sounds plausible on its surface. What's the migration path for helping current users deal with the changes here, it is just a matter of including it in the release notes for the new version, or are there more direct ways to give useful feedback to the people relying on the current behavior? |
I don't think so. Improving that also seems good to me.
I'm not sure. I don't have a sense of how often people are depending on the current behavior. I can't think of anything besides |
ehuss
added
enhancement
can cargo-bisect-rustc respect the .cargo/config.toml? (Should it already be doing so?)
As part of dissecting rust-lang/rust#111888, I was looking into adding a linker flag to the rustc invocations via a
.cargo/config.tomlfile, as described here: https://doc.rust-lang.org/cargo/reference/config.html#buildrustflagsBut it seems from my local experiments that while my manual invocations of
cargoare pulling in the config settings, the invocations thatcargo-bisect-rustcemits do not seem to be including the rustflags specified there.The text was updated successfully, but these errors were encountered: