Prefer sysroot from rustc in same directory as rust-gdb #70713
Conversation
If there isn't a rustc in the same directory, then fall back to searching the path.
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
I'm not really opposed to landing this, but I have heard I think in the past that adding Can you share your use case for this? I wouldn't have expected rustc to be in the current directory in common usage, but maybe there's some pattern I'm missing? |
|
@Mark-Simulacrum Not rustc in the current directory, but in the same directory as rust-gdb. So if rust-gdb is in Right now if I have a private build of the toolchain and I directly invoke rust-gdb (ie, not via $PATH), it will be using the sysroot of whatever rustc is in $PATH. With this PR it will use the rustc that's a sibling of rust-gdb, but if there isn't one it falls back to the current behaviour. |
|
Ah, okay, I think I misread the description. In that case, seems great; thanks for clarifying! I think this is generally the correct behavior given how we normally package things. @bors r+ |
|
📌 Commit 7a824c8 has been approved by |
bors
added
S-waiting-on-bors
Rollup of 5 pull requests Successful merges: - rust-lang#70519 (Tweak output of type params and constraints in the wrong order) - rust-lang#70704 (Make panic unwind the default for aarch64-*-windows-msvc targets) - rust-lang#70713 (Prefer sysroot from rustc in same directory as rust-gdb) - rust-lang#70739 (def_collector, visit_fn: account for no body) - rust-lang#70827 (Use smaller span for suggestion restricting lifetime) Failed merges: r? @ghost
If there isn't a rustc in the same directory, then fall back to searching
the path.