-
-
Notifications
You must be signed in to change notification settings - Fork 14.1k
Closed
Labels
A-incr-compArea: Incremental compilationArea: Incremental compilationC-bugCategory: This is a bug.Category: This is a bug.C-cleanupCategory: PRs that clean code up or issues documenting cleanup.Category: PRs that clean code up or issues documenting cleanup.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.WG-incr-compWorking group: Incremental compilationWorking group: Incremental compilation
Description
I came across impl_stable_hash_via_hash!() the other day and it seems very problematic because one can easily generate invalid HashStable implementations without even noticing:
#[derive(Hash)]
struct Foo<'tcx> {
def_id: DefId, // numeric value of def_id ends up in fingerprint,
ptr: *const c_void, // memory address ends up in fingerprint,
bar: Interned<'tcx, Bar>, // ditto
}
// Yay, three separate bugs in a single line!
impl_stable_hash_via_hash!(Foo);I think we should just remove the macro (or keep it local to the module that implements HashStable for basic types). #[derive(HashStable_Generic)] is available as a safe alternative.
rustc_lint_defs::Level looks like a case where this is already a problem because of the HirId in the contained LintExpectationId.
cc @rust-lang/wg-incr-comp
compiler-errors
Metadata
Metadata
Assignees
Labels
A-incr-compArea: Incremental compilationArea: Incremental compilationC-bugCategory: This is a bug.Category: This is a bug.C-cleanupCategory: PRs that clean code up or issues documenting cleanup.Category: PRs that clean code up or issues documenting cleanup.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.WG-incr-compWorking group: Incremental compilationWorking group: Incremental compilation