Remove forked rust dependency#19
Conversation
|
Going to test the integration with |
|
The integration tests in There are some problems with what becomes
There may be other changes in the json, these are the ones making the integration test fail. |
|
Another issue is this panic in the compiler. Could this be an unresolved issue in Stack trace here: DetailsThe call to |
|
Things are pretty fragile the moment. Sorry for that. For context, there were several competing forces that contributed to the current state of affairs:
Regarding the JSON output format breaking, it should be possible to the massage the output to what we had before --- I am not sure I will have time for that though. The second issue about the compiler error --- the bug is likely in our code --- many of these compiler queries (in this case, the misbehaving query is I hope this is helpful. |
|
This is helpful @sskeirik. @jberthold I will look into it when I can with you and we will figure out what we need to get mir-semantics accepting the current state, and document what needs to be improved of course |
This PR adds functionality to filter and normalise the json output when comparing output to the golden tests. Some cases when we want to normalise output: 1. `"NormalSym"` mangled function names will have a hash following `17h` that will [change when the compiler version changes](https://github.com/rust-lang/rust/blob/2ae9916816a448fcaab3b2da461de754eda0055a/compiler/rustc_symbol_mangling/src/lib.rs#L69-L76). ``` < "NormalSym": "_ZN3std2rt19lang_start_internal17h3166ab4c34d1da61E" --- > "NormalSym": "_ZN3std2rt19lang_start_internal17h51b943990c0e2c96E" ^----can ignore---^ ``` 2. `"symbol_name"` mangled function names will have a hash following `17h` that will [change when the compiler version changes](https://github.com/rust-lang/rust/blob/2ae9916816a448fcaab3b2da461de754eda0055a/compiler/rustc_symbol_mangling/src/lib.rs#L69-L76). ``` < "symbol_name": "_ZN4core3ops8function6FnOnce9call_once17h40ba616aaa505a69E" --- > "symbol_name": "_ZN4core3ops8function6FnOnce9call_once17hd98db8d17b807164E" ```
dkcumming
left a comment
There was a problem hiding this comment.
I think this is good enough to merge and get started on the next phase. I think there are some problems to solve, but we can focus on that after a push to get things all connected from start to finish.
| // FIXME: We dump extra static items here --- this should be handled better | ||
| for (_, alloc) in visited_allocs.iter() { | ||
| if let AllocInfo::Static(def) = alloc { | ||
| let mono_item = stable_mir::mir::mono::MonoItem::Fn(stable_mir::mir::mono::Instance::from(*def)); | ||
| let item_name = &mono_item_name(tcx, &mono_item); | ||
| if !items_clone.contains_key(item_name) { | ||
| println!("Items missing static with id {:?} and name {:?}", def, item_name); | ||
| items.push(mk_item(tcx, mono_item, item_name.clone())); | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
Going to make an issue for this, so that we are tracking peculiarities about the format
This PR removes the forked rust dependency by implementing the following two functions directly in smir_pretty (instead of in a forked rust compiler):
This is done by extending the functionality of
LinkNameCollectorto also collectTyandAllocIdmappings and renaming the combined collector toInternedValueCollector.EDIT: When running the panic example on rustc master, there is some weirdness where a static item called:
alloc::alloc::__rust_no_alloc_shim_is_unstableis generated which has no body. This static item appears to be referenced from several different allocations (can be seen by chasing pointers in allocations provenance table). If this funny static item is findable on other machines, we should document this issue. It may well be that this is an empty type that is never used at runtime, but I haven't gone in to check this yet.