-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Include path in stamp hash for debuginfo tests #54567
Conversation
The debuginfo tests are exposed to the environment in a couple of ways: the path to the gdb executable matters, as does the Python path used when loading lldb. This patch incorporates these paths into the hash that is written to the stamp file, so that changing the path will cause the tests to be re-run.
(rust_highfive has picked a reviewer for you, use r? to override) |
@bors r+ rollup |
📌 Commit e6ea19d has been approved by |
Actually @bors r- |
I see no problem with this, but I'd like to get the opinion from someone on @rust-lang/infra to make sure there are no hidden complications... Therefore, I'm going to |
DebugInfoLldb => { | ||
env::var_os("PATH").hash(&mut hash); | ||
env::var_os("PYTHONPATH").hash(&mut hash); | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, why do these need to be two separate code paths? I feel like we can hash equally independent of whether we have gdb configured; if we rerun the path uselessly that's more or less fine I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was just more precise; and also gdb can be configured with an explicit path in config.toml
. However, if you want both paths to be the same, that's easy enough to do.
This seems fine (no need to make changes with regards to gdb/lldb merging). @bors r+ |
📌 Commit e6ea19d has been approved by |
…k-Simulacrum Include path in stamp hash for debuginfo tests The debuginfo tests are exposed to the environment in a couple of ways: the path to the gdb executable matters, as does the Python path used when loading lldb. This patch incorporates these paths into the hash that is written to the stamp file, so that changing the path will cause the tests to be re-run.
…k-Simulacrum Include path in stamp hash for debuginfo tests The debuginfo tests are exposed to the environment in a couple of ways: the path to the gdb executable matters, as does the Python path used when loading lldb. This patch incorporates these paths into the hash that is written to the stamp file, so that changing the path will cause the tests to be re-run.
Rollup of 8 pull requests Successful merges: - #54564 (Add 1.29.1 release notes) - #54567 (Include path in stamp hash for debuginfo tests) - #54577 (rustdoc: give proc-macros their own pages) - #54590 (std: Don't let `rust_panic` get inlined) - #54598 (Remove useless lifetimes from `Pin` `impl`s.) - #54604 (Added help message for `self_in_typedefs` feature gate) - #54635 (Improve docs for std::io::Seek) - #54645 (Compute Android gdb version in compiletest)
The debuginfo tests are exposed to the environment in a couple of
ways: the path to the gdb executable matters, as does the Python path
used when loading lldb.
This patch incorporates these paths into the hash that is written to
the stamp file, so that changing the path will cause the tests to be
re-run.