mathieu/granite-rust
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

rustc_span: Reorder some ExpnData fields in accordance with comments

Browse source 
A drive-by change.
This commit is contained in:
Vadim Petrochenkov 2021-07-11 00:40:25 +03:00
parent ece6f68186
commit 4ba91a063d
1 changed files with 25 additions and 26 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

51
compiler/rustc_span/src/hygiene.rs
View file

@ -709,6 +709,31 @@ pub struct ExpnData {
/// call_site span would have its own ExpnData, with the call_site
/// pointing to the `foo!` invocation.
pub call_site: Span,
/// The crate that originally created this `ExpnData`. During
/// metadata serialization, we only encode `ExpnData`s that were
/// created locally - when our serialized metadata is decoded,
/// foreign `ExpnId`s will have their `ExpnData` looked up
/// from the crate specified by `Crate
krate: CrateNum,
/// The raw that this `ExpnData` had in its original crate.
/// An `ExpnData` can be created before being assigned an `ExpnId`,
/// so this might be `None` until `set_expn_data` is called
// This is used only for serialization/deserialization purposes:
// two `ExpnData`s that differ only in their `orig_id` should
// be considered equivalent.
#[stable_hasher(ignore)]
orig_id: Option<u32>,
/// Used to force two `ExpnData`s to have different `Fingerprint`s.
/// Due to macro expansion, it's possible to end up with two `ExpnId`s
/// that have identical `ExpnData`s. This violates the contract of `HashStable`
/// - the two `ExpnId`s are not equal, but their `Fingerprint`s are equal
/// (since the numerical `ExpnId` value is not considered by the `HashStable`
/// implementation).
///
/// The `disambiguator` field is set by `update_disambiguator` when two distinct
/// `ExpnId`s would end up with the same `Fingerprint`. Since `ExpnData` includes
/// a `krate` field, this value only needs to be unique within a single crate.
disambiguator: u32,
// --- The part specific to the macro/desugaring definition.
// --- It may be reasonable to share this part between expansions with the same definition,
@ -734,32 +759,6 @@ pub struct ExpnData {
pub macro_def_id: Option<DefId>,
/// The normal module (`mod`) in which the expanded macro was defined.
pub parent_module: Option<DefId>,
/// The crate that originally created this `ExpnData`. During
/// metadata serialization, we only encode `ExpnData`s that were
/// created locally - when our serialized metadata is decoded,
/// foreign `ExpnId`s will have their `ExpnData` looked up
/// from the crate specified by `Crate
krate: CrateNum,
/// The raw that this `ExpnData` had in its original crate.
/// An `ExpnData` can be created before being assigned an `ExpnId`,
/// so this might be `None` until `set_expn_data` is called
// This is used only for serialization/deserialization purposes:
// two `ExpnData`s that differ only in their `orig_id` should
// be considered equivalent.
#[stable_hasher(ignore)]
orig_id: Option<u32>,
/// Used to force two `ExpnData`s to have different `Fingerprint`s.
/// Due to macro expansion, it's possible to end up with two `ExpnId`s
/// that have identical `ExpnData`s. This violates the contract of `HashStable`
/// - the two `ExpnId`s are not equal, but their `Fingerprint`s are equal
/// (since the numerical `ExpnId` value is not considered by the `HashStable`
/// implementation).
///
/// The `disambiguator` field is set by `update_disambiguator` when two distinct
/// `ExpnId`s would end up with the same `Fingerprint`. Since `ExpnData` includes
/// a `krate` field, this value only needs to be unique within a single crate.
disambiguator: u32,
}
// These would require special handling of `orig_id`.