-
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
base: remove_kani
Are you sure you want to change the base?
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 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.