Skip to content

Conversation

@hkBst
Copy link
Member

@hkBst hkBst commented Nov 4, 2025

Continuation of #148348
r? @Urgau

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 4, 2025
@rustbot
Copy link
Collaborator

rustbot commented Nov 4, 2025

r? @lcnr

rustbot has assigned @lcnr.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot assigned Urgau and unassigned lcnr Nov 4, 2025
.note = pointers do not have a lifetime; when calling `{$callee}` the `{$ty}` will be deallocated at the end of the statement because nothing is referencing it as far as the type system is concerned
.help_bind = you must make sure that the variable you bind the `{$ty}` to lives at least as long as the pointer returned by the call to `{$callee}`
.help_returned = in particular, if this pointer is returned from the current function, binding the `{$ty}` inside the function will not suffice
lint_dangling_pointers_from_temporaries = expression creates a dangling pointer to dropped temporary `{$ty}`
Copy link
Member

@Urgau Urgau Nov 4, 2025

Choose a reason for hiding this comment

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

I'm not sure that's the a good description of the issue, I feel like it's a bit misleading, the temporary is not yet dropped (otherwise this would insta UB), it's dropped only after creating the pointer, and it's the dropping of the temporary which makes the pointer dangling.

The previously wording was clearer IMO on this point. Not sure how to best improve that.

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm, I thought that detail did not matter. Do you have a reference for your claim that that would be insta UB?

Copy link
Member

Choose a reason for hiding this comment

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

Do you have a reference for your claim that that would be insta UB?

For String::new().DROPPED.as_ptr() it's apparently a grey area rust-lang/unsafe-code-guidelines#188 where use-after-dropped and use-after-free are different regarding opsem. I was told that it should probably be UB and is heavily discouraged.

But for allocation like "".to_string().DROPPED.as_ptr() Miri flags it as UB1 on the as_ptr() call, so 🤷

Footnotes

  1. https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=1c4f3446888f2b92d486a5f478722640

.ret_ty = return type is `{$ret_ty}`
.local_var = local variable `{$local_var_name}` is dropped at the end of the {$fn_kind}
.created_at = dangling pointer created here
.help_visit = for more information, see <https://doc.rust-lang.org/reference/destructors.html>
Copy link
Member

Choose a reason for hiding this comment

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

That's not used right?

Copy link
Member Author

Choose a reason for hiding this comment

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

Right, I forgot to wire that up. Will fix.

.help_bind = you must make sure that the variable you bind the `{$ty}` to lives at least as long as the pointer returned by the call to `{$callee}`
.help_returned = in particular, if this pointer is returned from the current function, binding the `{$ty}` inside the function will not suffice
lint_dangling_pointers_from_temporaries = expression creates a dangling pointer to dropped temporary `{$ty}`
.label_ptr = dangling pointer created here
Copy link
Member

Choose a reason for hiding this comment

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

This also is misleading IMO, it's not yet dangling but it will be.

@Urgau Urgau 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 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants