-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Make debug_triple depend on target json file content rather than file path #98225
Conversation
… path This ensures that changes to target json files will force a recompilation. And more importantly that moving the files doesn't force a recompilation.
r? @nagisa (rust-highfive has picked a reviewer for you, use r? to override) |
|
This comment has been minimized.
This comment has been minimized.
@@ -2436,20 +2434,28 @@ impl TargetTriple { | |||
/// Creates a target triple from the passed target path. | |||
pub fn from_path(path: &Path) -> Result<Self, io::Error> { | |||
let canonicalized_path = path.canonicalize()?; |
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 should be fine to remove this canonicalize operation now I think. The only difference would be that the triple would be the original file stem rather than the canonicalized one. This may be preferred in case of content addressed storage as the canonicalized name would be a non human readable hash.
a76a577
to
8c296ae
Compare
This comment has been minimized.
This comment has been minimized.
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.
+1 on the general direction. r=me, up to you what to do with the nits inline.
( | ||
Self::TargetJson { path_for_rustdoc: _, triple: l_triple, contents: l_contents }, | ||
Self::TargetJson { path_for_rustdoc: _, triple: r_triple, contents: r_contents }, | ||
) => l_triple == r_triple && l_contents == r_contents, |
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.
Minor style nit, consider:
( | |
Self::TargetJson { path_for_rustdoc: _, triple: l_triple, contents: l_contents }, | |
Self::TargetJson { path_for_rustdoc: _, triple: r_triple, contents: r_contents }, | |
) => l_triple == r_triple && l_contents == r_contents, | |
(l@Self::TargetJson { .. }, r@Self::TargetJson { .. }) => { | |
l.triple == r.triple && l.contents == r.contents | |
} |
or, if the intent was to have this an exhaustive match, maybe something like this (though there isn’t much value in this…):
( | |
Self::TargetJson { path_for_rustdoc: _, triple: l_triple, contents: l_contents }, | |
Self::TargetJson { path_for_rustdoc: _, triple: r_triple, contents: r_contents }, | |
) => l_triple == r_triple && l_contents == r_contents, | |
(Self::TargetJson { path_for_rustdoc: _, triple, contents }, r@Self::TargetJson { .. }) => { | |
triple == r.triple && contents == r.contents | |
} |
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.
or, if the intent was to have this an exhaustive match
Indeed
maybe something like this
Rustfmt puts that suggestion on four lines too.
|
||
impl<D: Decoder> Decodable<D> for TargetTriple { | ||
fn decode(d: &mut D) -> Self { | ||
match d.read_usize() { |
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.
This is a little sketchy. This could fail if the implementation of the encoder has overriden emit_enum_variant
to output something else than usize… Though of course Decoder
does not provide a better way 🤷
Fixed all review comments apart from #98225 (comment) |
This comment was marked as resolved.
This comment was marked as resolved.
consider squashing the history somewhat before |
622015a
to
b4b536d
Compare
@bors r=nagisa |
📌 Commit b4b536d has been approved by |
…agisa Make debug_triple depend on target json file content rather than file path This ensures that changes to target json files will force a recompilation. And more importantly that moving the files doesn't force a recompilation. This should fix Rust-for-Linux/linux#792 (cc `@ojeda)`
Rollup of 4 pull requests Successful merges: - rust-lang#95534 (Add `core::mem::copy` to complement `core::mem::drop`.) - rust-lang#97912 (Stabilize `Path::try_exists()` and improve doc) - rust-lang#98225 (Make debug_triple depend on target json file content rather than file path) - rust-lang#98257 (Fix typos in `IntoFuture` docs) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
The first change is to parse once, and then use an enum for the device. This is hopefully a straightforward improvement. The second change is to case on the OS name (leveraging LedgerHQ#38) instead of the target name. The target "name" isn't so structured, and it is unclear to what extent it should be anm exposed part of the target. (See rust-lang/rust#98225 for example, where the contents rather than json file path were used as a a key.) With LedgerHQ#38 the device name is used for the OS field instead, and so we are robust to confusing behavior around names.
The first change is to parse once, and then use an enum for the device. This is hopefully a straightforward improvement. The second change is to case on the OS name (leveraging #38) instead of the target name. The target "name" isn't so structured, and it is unclear to what extent it should be anm exposed part of the target. (See rust-lang/rust#98225 for example, where the contents rather than json file path were used as a a key.) With #38 the device name is used for the OS field instead, and so we are robust to confusing behavior around names.
This gives us some warnings, but allows to compile out-of-tree modules since it fixes a bug with how the target triple is defined for a custom target.json file. See rust-lang/rust#98225
The first change is to parse once, and then use an enum for the device. This is hopefully a straightforward improvement. The second change is to case on the OS name (leveraging #38) instead of the target name. The target "name" isn't so structured, and it is unclear to what extent it should be anm exposed part of the target. (See rust-lang/rust#98225 for example, where the contents rather than json file path were used as a a key.) With #38 the device name is used for the OS field instead, and so we are robust to confusing behavior around names.
This ensures that changes to target json files will force a recompilation. And more importantly that moving the files doesn't force a recompilation.
This should fix Rust-for-Linux/linux#792 (cc @ojeda)