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

borrowck: Prevent partial reinitialization of uninitialized structures #22079

Closed
wants to merge 2 commits into from

Conversation

Ryman
Copy link
Contributor

@Ryman Ryman commented Feb 8, 2015

This is a rebase of #18963

2nd commit is to accommodate @nikomatsakis's comments on the PR which handles his additional testcase.
Will squash post-review if it's adequate.

Fixes #18571.

cc @pcwalton @nikomatsakis

pcwalton and others added 2 commits February 8, 2015 04:32
enumerations that implement the `Drop` trait.

This breaks code like:

    struct Struct {
        f: String,
        g: String,
    }

    impl Drop for Struct { ... }

    fn main() {
        let x = Struct { ... };
        drop(x);
        x.f = ...;
    }

Change this code to not create partially-initialized structures. For
example:

    struct Struct {
        f: String,
        g: String,
    }

    impl Drop for Struct { ... }

    fn main() {
        let x = Struct { ... };
        drop(x);
        x = Struct {
            f: ...,
            g: ...,
        }
    }

Closes rust-lang#18571.

[breaking-change]
@rust-highfive
Copy link
Collaborator

r? @pnkfelix

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

if ty::has_dtor(self.tcx(), def_id) {
// In the case where the owner implements drop, then
// the path must be initialized to prevent a case of
// partial reinitialization
Copy link
Member

Choose a reason for hiding this comment

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

This code is an improvement on the prior PR that you rebased, thanks!

However, I do wonder whether we could simplify further and just call self.check_if_path_is_moved(id, span, use_kind, lp_base); after doing the ty::has_dtor check, the same way that the other cases below do.

Does that produce an error message that is too obscure? (Or, is there some technical reason we cannot do that?)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Off the top of my head, it was possible but the error was a more generic 'use of moved value foo.bar'.

I reasoned that the improved error message from the original changeset might be preferable but I'm willing to change it for simpler code.

Copy link
Member

Choose a reason for hiding this comment

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

How about this: Keep your code the way it is, but throw in a FIXME here and above fn check_if_path_is_moved noting that the body of check_if_path_is_moved is largely the same as the code you put into this function. That way, if someone does this same thing again, maybe we will then be inspired to refactor the code, parameterizing over what error message to report (since that is AFAICT the only thing that is changing between the two fragements of code).

(That, or you could add in such a refactoring yourself, as a followup commit post squash.)

That way, we keep a nice precision in the error messages, and we slightly reduce the risk that this code fragment will be cut-and-pasted into other contexts without an attempt to pull it all together.

@pnkfelix
Copy link
Member

The tests look good to me.

@Ryman r=me after squashing (and I would like an answer to the question above if possible).


Update: okay, my question has been answered. So r=me after squashing and adding the FIXME i asked for above. (If you do the refactoring I suggested, just ping me for a re-review.)

@pnkfelix
Copy link
Member

(the bors queue is close to empty right now, so I might just steal this and make a fresh PR for it.)

@pnkfelix
Copy link
Member

closing in favor of #22219 (which just does the squashing); thanks for the contribution, I made sure to preserve your authorship on the squash. :)

@pnkfelix pnkfelix closed this Feb 12, 2015
@Ryman
Copy link
Contributor Author

Ryman commented Feb 12, 2015

@pnkfelix No worries, I didn't notice this before going ahead with a quick refactor, you can check Ryman@d57d5f3 to see if it warrants pulling in or not. (The alternative, taking a closure didn't really remove much duplication)

bors added a commit that referenced this pull request Feb 13, 2015
borrowck: Prevent partial reinitialization of uninitialized structures

This is a pnkfelix-swiped squash of #22079, which was a rebase and revision of #18963

Fixes #18571.
nivkner added a commit to nivkner/rust that referenced this pull request Oct 7, 2017
update FIXME(rust-lang#6298) to point to open issue 15020
update FIXME(rust-lang#6268) to point to RFC 811
update FIXME(rust-lang#10520) to point to RFC 1751
remove FIXME for emscripten issue 4563 and include target in `test_estimate_scaling_factor`
remove FIXME(rust-lang#18207) since node_id isn't used for `ref` pattern analysis
remove FIXME(rust-lang#6308) since DST was implemented in rust-lang#12938
remove FIXME(rust-lang#2658) since it was decided to not reorganize module
remove FIXME(rust-lang#20590) since it was decided to stay conservative with projection types
remove FIXME(rust-lang#20297) since it was decided that solving the issue is unnecessary
remove FIXME(rust-lang#27086) since closures do correspond to structs now
remove FIXME(rust-lang#13846) and enable `function_sections` for windows
remove mention of rust-lang#22079 in FIXME(rust-lang#22079) since this is a general FIXME
remove FIXME(rust-lang#5074) since the restriction on borrow were lifted
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.

Undetected use after move
4 participants