In the following rust file:
#[cfg(true)]
pub fn main() {
}
The function main has a different HIR stable hash than in the following rust file
// Whitespace here
#[cfg(true)]
pub fn main() {
}
This is because in the HIR, during attribute lowering, attributes are hashed relative to their parents definition's span. For outer attributes, their parent definition is the definition they're placed on. However, their parent definition's span does not actually include outer attributes.
This causes the following check to fail:
|
if def_span.contains(span) { |
Meaning the attribute is not hashed relative to its parent. This could potentially have very significant performance implications for incremental.
cc @jdonszelmann as a person who knows about attributes
cc @cjgillot as the author of #84373, what do you think is a good fix for this?
The easiest fix is probably to allow for negative numbers in relative encoding. I'll try to make a PR for this later,
In the following rust file:
The function
mainhas a different HIR stable hash than in the following rust fileThis is because in the HIR, during attribute lowering, attributes are hashed relative to their parents definition's span. For outer attributes, their parent definition is the definition they're placed on. However, their parent definition's span does not actually include outer attributes.
This causes the following check to fail:
rust/compiler/rustc_span/src/lib.rs
Line 2871 in 2e854a9
Meaning the attribute is not hashed relative to its parent. This could potentially have very significant performance implications for incremental.
cc @jdonszelmann as a person who knows about attributes
cc @cjgillot as the author of #84373, what do you think is a good fix for this?
The easiest fix is probably to allow for negative numbers in relative encoding. I'll try to make a PR for this later,