-
Notifications
You must be signed in to change notification settings - Fork 0
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
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:
The 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" ```
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
LinkNameCollector
to also collectTy
andAllocId
mappings 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_unstable
is 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.