strict version hash (SVH) incorporates hidden implementation artifacts #14132
Comments
alexcrichton
pushed a commit
to alexcrichton/rust
that referenced
this issue
May 15, 2014
In particular, this version of strict version hash (SVH) works much like the deriving(Hash)-based implementation did, except that uses a content-based hash that filters rustc implementation artifacts and surface syntax artifacts. Fix rust-lang#14132.
bors
added a commit
that referenced
this issue
May 15, 2014
…excrichton
Teach SVH computation to ignore more implementation artifacts.
In particular, this version of strict version hash (SVH) works much
like the deriving(Hash)-based implementation did, except that it
deliberately:
1. skips over content known not affect the generated crates, and,
2. uses a content-based hash for names instead of using the value of
the `Name` index itself, which can differ depending on the order
in which strings are interned (which in turn is affected by
e.g. the presence of `--cfg` options on the command line).
Fix #14132.
Closed
richo
added a commit
to richo/rust
that referenced
this issue
Aug 1, 2015
This makes the hash of a crate no longer whitespace dependant on it's attributes Ping rust-lang#14132
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Feb 13, 2023
feat: Add clippy configuration section to the manual and update some old keys Closes rust-lang#14132 I don't think this is supposed to be under `Diagnostics`, but it does make sense in a way 🤷 (it's probably where someone might look).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Spawned off of investigation from PR #13948 (but really is a long-standing known issue).
If you look at the comments on svh.rs you see that our current strict version hash (SVH) scheme is too fine-grained: the hash computation is using details of the ast and attributes that should be irrelevant to the hash.
Worse still, @alexcrichton discovered while looking at problems with PR #13948 that the hash is even incorporating implementation artifacts like the order in which identifiers are interned. This means that the order in which one passes command line flags like
--cfg stage1affects the SVH value. That is bad.This may be easy to fix, depending on how far we want to go with it. It seems like one reason we have not yet fixed this is because we haven't decided how simple we want this hash computation to be, as discussed on Issue #10208.
See also Issue #10207 for the original motivation for SVH, PR #12533, which has some discussion (including even of the
--cfgproblem mentioned above).The text was updated successfully, but these errors were encountered: