type_id is not crate-independent with object associated types

[arielb1]

Meta

$ rustc -V
rustc 1.12.0-dev (5556554e2 2016-07-31)

STR

#![feature(core_intrinsics, rustc_private)]

#[cfg(arena_first)]
extern crate arena;
extern crate term;
#[cfg(not(arena_first))]
extern crate arena;

use std::intrinsics::type_id;

fn main() { unsafe {
    println!("same={:?} different={:?}",
        type_id::<arena::TypedArena<()>>(),
        type_id::<Iterator<Item=arena::TypedArena<()>>>()
    );
}}  

Any pair of crates, one of them with a struct, can be used instead of arena/term.

Expected Result

The Type ID of Iterator<Item=arena::TypedArena<()>> should be the same when the cfg is toggled.

Actual Result

The Type ID of Iterator<Item=arena::TypedArena<()>> differs when the cfg is toggled, but the id of arena::TypedArena<()> does not

[michaelwoerister]

This is probably the same underlying issue that has been solved for tyencode in #34805.
Projection bounds should be hashed in deterministic order.

[arielb1]

This should be fixed - projections are now sorted by their DefPath.

[TornaxO7]

Is this issue still up to date?

[apiraino]

I've tested this with some more modern Rust code:

#![feature(core_intrinsics, rustc_private)]                                                                                   

use term;
#[cfg(arena_first)]
use typed_arena;
#[cfg(not(arena_first))]
use typed_arena;

use std::intrinsics::type_id;
 
 fn main() {
     println!(
         "same={:?} different={:?}",
         type_id::<typed_arena::Arena<()>>(),
         type_id::<dyn Iterator<Item = typed_arena::Arena<()>>>()
     );
 }

the Type IDs are now the same compiling with or without --features arena_first, ex:

$ cargo run --features arena_first
same=183576685912587470318627960423020482748 different=30593087131907206016297065634067928062
$ cargo run
same=183576685912587470318627960423020482748 different=30593087131907206016297065634067928062

[apiraino]

reopen as it needs a test, possibly reducing to no external dependencies

[jackh726]

This has an MCVE, just needs test (and there is an open PR).