-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Struct{x:y, .. old.method_taking_self()} doesn't treat old as a moved value #18567
Milestone
Comments
brandonson
changed the title
Using Struct{x:y, .. old.method_taking_self()} doesn't treat old as a moved value
Struct{x:y, .. old.method_taking_self()} doesn't treat old as a moved value
Nov 3, 2014
Nominating for P-high, this is an obvious soundness hole. |
ghost
self-assigned this
Nov 3, 2014
As a heads up, I'm working on fixing this with a bit of guidance from eddyb on IRC, whoever he is here! Looks like the with expression wasn't being walked by visitors, but fields from the result were consumed. |
ghost
removed their assignment
Nov 3, 2014
brandonson
added a commit
to brandonson/rust
that referenced
this issue
Nov 6, 2014
Fixes rust-lang#18567. Struct{x:foo, .. with_expr} did not walk with_expr, which allowed using moved variables in some cases. The CFG for structs also built up with with_expr happening before the fields, which is now reversed. (Fields are now before the with_expr in the CFG)
Assigning P-backcompat-lang, 1.0. |
bors
added a commit
that referenced
this issue
Nov 7, 2014
…matsakis Fixes #18567. `Struct{x:foo, .. with_expr}` did not walk `with_expr`, which allowed using moved variables in some cases. The CFG for structs also built up with `with_expr` happening before the fields, which is now reversed. (Fields are now before the `with_expr` in the CFG)
lnicola
added a commit
to lnicola/rust
that referenced
this issue
Dec 11, 2024
minor: fix proc macro test
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In this code, the call to start.make_string_bar() should move start, but start can still be used by the println:
This specific example of the bug doesn't do anything terrible for me, it just doesn't print anything. However, this appears to trample variable values, as I first ran into this with more complex code where it caused a segfault.
Changing
start.test
in the println toend.test
prints bar, as expected. ChangingMine{other_val:1, ..start.make_string_bar()}
toMine{other_val:1, ..start}
causes compiler errors at the println saying start has moved, which is also correct.The text was updated successfully, but these errors were encountered: