-
Notifications
You must be signed in to change notification settings - Fork 97
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
Account for use
statements when resolving paths in kani::stub
attributes
#2003
Conversation
8a0a9d4
to
8d82d81
Compare
8d82d81
to
fa6a70f
Compare
8946d5a
to
3c101d3
Compare
@celinval FYI, this is ready for review, but a maintainer needs to start the CI job. |
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.
Sorry, I haven't had time to go through the entire PR yet. FYI, I'll be off next week.
fn module_to_string(tcx: TyCtxt, current_module: LocalDefId) -> String { | ||
let def_id = current_module.to_def_id(); | ||
if def_id.is_crate_root() { | ||
"crate root".to_string() |
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.
Can you either change this to be the name of the current create or something like crate $root
? It could get confusing if the user has a crate named "root"
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 changed this to the name of the root module.
// TODO: We should make this consistent with error handling for other | ||
// cases (see <https://github.com/model-checking/kani/issues/2013>). | ||
let location = module_to_string(tcx, current_module); | ||
let mut msg = format!( |
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.
Maybe change this to:
Unable to resolve `{stub name}`. Ambiguous de definitions found due to the following imports:
...
Also, do we have the span from the stub declaration? I think that would really help here.
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.
We currently don't have the span available anywhere in this module, and at this point in the code we don't even have the full name of the original function we're trying to resolve. We could potentially pass this information around all the different resolution functions so that we can produce helpful error messages here. However, I think it would be cleaner to change the resolution functions to return a Result
and then leave it up to the client of this module to produce error messages.
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.
You could wrap these functions into a type that holds that information so you can generate more helpful error messages. Not on this PR though. :)
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.
Okay, sounds like we're holding off on making changes here until later. I think it probably makes most sense to go with the approach of returning a Result
, so that this resolve
module does not become specialized to stubbing, but can also be used in other parts of Kani.
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.
BTW, my suggestion is to keep it independent from stubbing. I'm OK with returning a result too, and letting the user to decide whether the failure to resolve is an error or not.
My main point is that the message should give more context on the exact path that we are trying to resolve and in which level it has failed.
Thanks for taking an initial look! I will also be off until mid-January. |
updates on this? |
I don't think @aaronbembenek is back yet. |
That’s right - I’m currently on vacation, but I’ll have some time to make
updates starting next week.
…On Tue, Jan 10, 2023 at 10:33 AM Celina G. Val ***@***.***> wrote:
I don't think @aaronbembenek <https://github.com/aaronbembenek> is back
yet.
—
Reply to this email directly, view it on GitHub
<#2003 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABSS5S732XP5UWUFABHYAEDWRSN5JANCNFSM6AAAAAAS724WRA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
3c101d3
to
d3f87d8
Compare
d3f87d8
to
b9e314c
Compare
Okay, I'm back now! Let me know what other changes to make... |
Also, looks like I need someone to approve this workflow... |
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.
Thanks
Thanks @celinval for taking a look! You might have to merge this for me (I don't think I have permissions to). |
Description of changes:
This PR follows up on #1999.
Currently, when we resolve paths appearing in
kani::stub
attributes, we do not take into account anyuse
statements that might be in play. This PR fixes this gap by accounting for these types of imports:use XXX;
use XXX as YYY;
use XXX::*
extern crate XXX as YYY;
Resolved issues:
Resolves #1998
Related #1866
Related #1997
Call-outs:
Some care had to be taken so that we handle glob imports correctly, as paths resolved through them essentially have a lower priority than paths resolved other ways.
Testing:
How is this change tested? New tests
Is this a refactor change? No
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.