Skip to content
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

incr.comp.: Fix HashStable for ty::RegionKind and trans item order #45176

Merged
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions src/librustc/ich/impls_ty.rs
Original file line number Diff line number Diff line change
Expand Up @@ -61,6 +61,9 @@ for ty::RegionKind {
def_id.hash_stable(hcx, hasher);
name.hash_stable(hcx, hasher);
}
ty::ReLateBound(db, ty::BrEnv) => {
db.depth.hash_stable(hcx, hasher);
}
ty::ReEarlyBound(ty::EarlyBoundRegion { def_id, index, name }) => {
def_id.hash_stable(hcx, hasher);
index.hash_stable(hcx, hasher);
Expand Down
23 changes: 20 additions & 3 deletions src/librustc_trans/partitioning.rs
Original file line number Diff line number Diff line change
Expand Up @@ -163,10 +163,27 @@ pub trait CodegenUnitExt<'tcx> {
fn item_sort_key<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>,
item: TransItem<'tcx>) -> ItemSortKey {
ItemSortKey(match item {
TransItem::Fn(instance) => {
tcx.hir.as_local_node_id(instance.def_id())
TransItem::Fn(ref instance) => {
match instance.def {
// We only want to take NodeIds of user-defined
// instances into account. The others don't matter for
// the codegen tests and can even make item order
// unstable.
InstanceDef::Item(def_id) => {
tcx.hir.as_local_node_id(def_id)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we sort instead by def_id?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure that DefIds also reflect definition order. They probably do. This whole thing is a bit of a hack anyway. We could sort by Span...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DefIds do not reflect definition order, except in anonymous cases like impls. Otherwise, they would sort by name. Why do we care if these are reflect "definition order" per se?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I makes writing the codegen tests a lot more pleasant if you know in which order things will appear in LLVM IR. You could of course also run the compiler once to find out what the order is but that's another hurdle to writing such tests. Also the tests might break if we changed the details of our symbol mangling (which we've done quite a few times). What we have now is "OK" in comparison, I think.

}
InstanceDef::Intrinsic(..) |
InstanceDef::FnPtrShim(..) |
InstanceDef::Virtual(..) |
InstanceDef::ClosureOnceShim { .. } |
InstanceDef::DropGlue(..) |
InstanceDef::CloneShim(..) => {
None
}
}
}
TransItem::Static(node_id) | TransItem::GlobalAsm(node_id) => {
TransItem::Static(node_id) |
TransItem::GlobalAsm(node_id) => {
Some(node_id)
}
}, item.symbol_name(tcx))
Expand Down