Skip to content
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

Merged
merged 4 commits into from
Jan 19, 2023

Conversation

aaronbembenek-aws
Copy link
Contributor

@aaronbembenek-aws aaronbembenek-aws commented Dec 15, 2022

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 any use 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

  • Each commit message has a non-empty body, explaining why the change was made
  • Methods or procedures are documented
  • Regression or unit tests are included, or existing tests cover the modified code
  • My PR is restricted to a single feature or bugfix

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

@aaronbembenek-aws aaronbembenek-aws force-pushed the resolve-uses branch 2 times, most recently from 8a0a9d4 to 8d82d81 Compare December 16, 2022 20:55
@aaronbembenek-aws aaronbembenek-aws marked this pull request as ready for review December 19, 2022 14:08
@aaronbembenek-aws aaronbembenek-aws requested a review from a team as a code owner December 19, 2022 14:08
@aaronbembenek-aws
Copy link
Contributor Author

@celinval FYI, this is ready for review, but a maintainer needs to start the CI job.

Copy link
Contributor

@celinval celinval left a 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()
Copy link
Contributor

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"

Copy link
Contributor

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!(
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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. :)

Copy link
Contributor

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.

Copy link
Contributor

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.

@aaronbembenek-aws
Copy link
Contributor Author

Thanks for taking an initial look! I will also be off until mid-January.

@rahulku
Copy link
Contributor

rahulku commented Jan 9, 2023

updates on this?

@celinval
Copy link
Contributor

celinval commented Jan 9, 2023

I don't think @aaronbembenek is back yet.

@aaronbembenek
Copy link
Contributor

aaronbembenek commented Jan 11, 2023 via email

@aaronbembenek
Copy link
Contributor

Okay, I'm back now! Let me know what other changes to make...

@aaronbembenek
Copy link
Contributor

Also, looks like I need someone to approve this workflow...

Copy link
Contributor

@celinval celinval left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks

@aaronbembenek
Copy link
Contributor

Thanks @celinval for taking a look! You might have to merge this for me (I don't think I have permissions to).

@celinval celinval merged commit 65b431c into model-checking:main Jan 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Take into account use statements when resolving stub paths
4 participants