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

Improve uninit/zeroed lint #66044

Merged
merged 3 commits into from
Nov 7, 2019
Merged

Improve uninit/zeroed lint #66044

merged 3 commits into from
Nov 7, 2019

Conversation

RalfJung
Copy link
Member

@RalfJung RalfJung commented Nov 2, 2019

  • Also warn when creating a raw pointer with a NULL vtable.
  • Also identify MaybeUninit::uninit().assume_init() and MaybeUninit::zeroed().assume_init() as dangerous.

@rust-highfive
Copy link
Collaborator

r? @varkor

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 2, 2019
}
} else if let hir::ExprKind::MethodCall(ref path, _, ref args) = expr.kind {
// Find problematic calls to `MaybeUninit::assume_init`.
if path.ident.name == sym::assume_init {
Copy link
Member Author

Choose a reason for hiding this comment

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

This one seems odd to me. I am comparing just the name of the method -- but what if there is a trait or another type or so that also had this method? This looks like I am working pre-resolution, which seems fragile. Isn't there any way to get the full path to the method that will actually be called here?

I looked at clippy but couldn't find anything less fragile there either. Cc @oli-obk @Manishearth

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 use diagnostics items instead? #60966

Copy link
Member Author

Choose a reason for hiding this comment

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

Hm, I have an Option<HirId>; I guess I could unwrap that and then call owner_def_id to get the DefId that is_diagnostic_item needs.

Copy link
Member Author

Choose a reason for hiding this comment

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

Nope, that does not work. The lint just never fires. Looks like the HirId I get there is not pointing to the method being called -- that kind of makes sense if the information we have here is pre-method-resolution. (Probably it's the HirId of the method call itself.)

For Call, I can call

cx.tables.qpath_res(qpath, path_expr.hir_id).opt_def_id()?

to get the def_id of the callee. Isn't there something similar for MethodCall?

Copy link
Member Author

Choose a reason for hiding this comment

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

Hm, maybe I need to construct a QPath::TypeRelative? I have a PathSegment, but I'd still also need a Ty.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah, I found a way:

cx.tables.type_dependent_def_id(expr.hir_id)?

Here, expr is the MethodCall itself.

if let hir::ExprKind::Call(ref path_expr, _) = args[0].kind {
if let hir::ExprKind::Path(ref qpath) = path_expr.kind {
let def_id = cx.tables.qpath_res(qpath, path_expr.hir_id).opt_def_id()?;
if cx.match_def_path(def_id, MU_ZEROED_PATH) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't this (and the other one below) also use diagnostics items?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, see #66075. This is partially pre-existing. I didn't feel like rewriting the entire lint at once.^^

Copy link
Contributor

Choose a reason for hiding this comment

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

yea we should be moving away from match_def_path where we can. That's the reason diagnostic items were introduced

Copy link
Contributor

Choose a reason for hiding this comment

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

@RalfJung Sure that's fair about the old code... but these are additions?

Copy link
Member Author

Choose a reason for hiding this comment

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

But I guess this is as good as any a time to resolve the first bullet point from that issue. Not sure when I'll get to it, though.

@Centril
Copy link
Contributor

Centril commented Nov 6, 2019

r? @Centril

r=me with or without changing all the additions to using diagnostics items (hopefully that will happen in a follow up if not done here -- remember however to cleanup symbol.rs after you're done either way ^^).

@rust-highfive rust-highfive assigned Centril and unassigned varkor Nov 6, 2019
@Centril Centril added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 6, 2019
@oli-obk
Copy link
Contributor

oli-obk commented Nov 6, 2019

@bors r+ having a tracking issue seems fine. It's a WIP in clippy, too.

@bors
Copy link
Contributor

bors commented Nov 6, 2019

📌 Commit bb37d00 has been approved by oli-obk

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 6, 2019
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Nov 6, 2019
Improve uninit/zeroed lint

* Also warn when creating a raw pointer with a NULL vtable.
* Also identify `MaybeUninit::uninit().assume_init()` and `MaybeUninit::zeroed().assume_init()` as dangerous.
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Nov 7, 2019
Improve uninit/zeroed lint

* Also warn when creating a raw pointer with a NULL vtable.
* Also identify `MaybeUninit::uninit().assume_init()` and `MaybeUninit::zeroed().assume_init()` as dangerous.
bors added a commit that referenced this pull request Nov 7, 2019
Rollup of 12 pull requests

Successful merges:

 - #65794 (gate rustc_on_unimplemented under rustc_attrs)
 - #65945 (Optimize long-linker-command-line test)
 - #66044 (Improve uninit/zeroed lint)
 - #66076 (HIR docs: mention how to resolve method paths)
 - #66084 (Do not require extra LLVM backends for `x.py test` to pass)
 - #66111 (improve from_raw_parts docs)
 - #66114 (Improve std::thread::Result documentation)
 - #66117 (Fixed PhantomData markers in Arc and Rc)
 - #66146 (Remove unused parameters in `__thread_local_inner`)
 - #66147 (Miri: Refactor to_scalar_ptr out of existence)
 - #66162 (Fix broken link in README)
 - #66171 (Update link on CONTRIBUTING.md)

Failed merges:

r? @ghost
@bors bors merged commit bb37d00 into rust-lang:master Nov 7, 2019
@RalfJung RalfJung deleted the uninit-lint branch November 7, 2019 08:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants