Skip to content

Conversation

Qelxiros
Copy link
Contributor

@Qelxiros Qelxiros commented Jul 24, 2025

Tracking issue: #144419

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jul 24, 2025
@rust-log-analyzer

This comment has been minimized.

@Qelxiros Qelxiros marked this pull request as ready for review July 25, 2025 00:12
@rustbot
Copy link
Collaborator

rustbot commented Jul 25, 2025

r? @thomcc

rustbot has assigned @thomcc.
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 added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 25, 2025
@Qelxiros
Copy link
Contributor Author

As far as I can tell, the ICE here is because of the function signature of Box::try_map. The return type is equivalent to ChangeOutputType<...> from the ACP, but that definition is in core, so I implemented it manually here. However, when I add the same type alias to alloc, the ICE persists. Is there a workaround here that remains in the spirit of the ACP? Is this a known compiler bug?

Copy link
Member

@joboet joboet left a comment

Choose a reason for hiding this comment

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

I have no clue about the ICE – perhaps try filing an issue?

View changes since this review

@Qelxiros Qelxiros force-pushed the smart_pointer_try_map branch from d5d5fea to 929d326 Compare September 2, 2025 20:53
@rustbot

This comment has been minimized.

@Qelxiros Qelxiros force-pushed the smart_pointer_try_map branch from 929d326 to 6a69f39 Compare September 2, 2025 20:57
@rustbot

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@Qelxiros Qelxiros force-pushed the smart_pointer_try_map branch from 64b65c1 to bfc61d6 Compare September 4, 2025 00:21
@rust-log-analyzer

This comment has been minimized.

@Qelxiros
Copy link
Contributor Author

Qelxiros commented Sep 4, 2025

I'm not sure how to move forward given the ICE (issue #146174).

@rustbot label +S-blocked

@rustbot rustbot added the S-blocked Status: Blocked on something else such as an RFC or other implementation work. label Sep 4, 2025
tgross35 added a commit to tgross35/rust that referenced this pull request Sep 5, 2025
…iler-errors

fix ICE when suggesting `::new`

fixes rust-lang#146174

This code suggests to write `Foo::new(...)` when the user writes `Foo(...)` or `Foo { ... }` and the constructor is private, where `new` is some associated function that returns `Self`.

When checking that the return type of `new` is `Self`, we need to instantiate the parameters of `new` with infer vars, so we don't end up with a type like `Box<$param(0)>` in a context that doesn't have any parameters. But then we can't use `normalize_erasing_late_bound_regions` anymore because that goes though a query that can't deal with infer vars.

Since this is diagnostic-only code that is supposed to check for exactly `-> Self`, I think it's fine to just skip normalizing here, especially since The Correct Way<sup>TM</sup> would involve a probe and make this code even more complicated.

Also, the code here does almost the same thing, and these suggestions can probably be unified in the future: https://github.com/rust-lang/rust/blob/4ca8078d37c53ee4ff8fb32b4453b915116f25b8/compiler/rustc_hir_typeck/src/method/suggest.rs#L2123-L2129

r? `@compiler-errors`
cc `@Qelxiros` -- this should unblock rust-lang#144420
tgross35 added a commit to tgross35/rust that referenced this pull request Sep 5, 2025
…iler-errors

fix ICE when suggesting `::new`

fixes rust-lang#146174

This code suggests to write `Foo::new(...)` when the user writes `Foo(...)` or `Foo { ... }` and the constructor is private, where `new` is some associated function that returns `Self`.

When checking that the return type of `new` is `Self`, we need to instantiate the parameters of `new` with infer vars, so we don't end up with a type like `Box<$param(0)>` in a context that doesn't have any parameters. But then we can't use `normalize_erasing_late_bound_regions` anymore because that goes though a query that can't deal with infer vars.

Since this is diagnostic-only code that is supposed to check for exactly `-> Self`, I think it's fine to just skip normalizing here, especially since The Correct Way<sup>TM</sup> would involve a probe and make this code even more complicated.

Also, the code here does almost the same thing, and these suggestions can probably be unified in the future: https://github.com/rust-lang/rust/blob/4ca8078d37c53ee4ff8fb32b4453b915116f25b8/compiler/rustc_hir_typeck/src/method/suggest.rs#L2123-L2129

r? ```@compiler-errors```
cc ```@Qelxiros``` -- this should unblock rust-lang#144420
tgross35 added a commit to tgross35/rust that referenced this pull request Sep 5, 2025
…iler-errors

fix ICE when suggesting `::new`

fixes rust-lang#146174

This code suggests to write `Foo::new(...)` when the user writes `Foo(...)` or `Foo { ... }` and the constructor is private, where `new` is some associated function that returns `Self`.

When checking that the return type of `new` is `Self`, we need to instantiate the parameters of `new` with infer vars, so we don't end up with a type like `Box<$param(0)>` in a context that doesn't have any parameters. But then we can't use `normalize_erasing_late_bound_regions` anymore because that goes though a query that can't deal with infer vars.

Since this is diagnostic-only code that is supposed to check for exactly `-> Self`, I think it's fine to just skip normalizing here, especially since The Correct Way<sup>TM</sup> would involve a probe and make this code even more complicated.

Also, the code here does almost the same thing, and these suggestions can probably be unified in the future: https://github.com/rust-lang/rust/blob/4ca8078d37c53ee4ff8fb32b4453b915116f25b8/compiler/rustc_hir_typeck/src/method/suggest.rs#L2123-L2129

r? ````@compiler-errors````
cc ````@Qelxiros```` -- this should unblock rust-lang#144420
rust-timer added a commit that referenced this pull request Sep 5, 2025
Rollup merge of #146217 - lukas-code:suggest-new-ice, r=compiler-errors

fix ICE when suggesting `::new`

fixes #146174

This code suggests to write `Foo::new(...)` when the user writes `Foo(...)` or `Foo { ... }` and the constructor is private, where `new` is some associated function that returns `Self`.

When checking that the return type of `new` is `Self`, we need to instantiate the parameters of `new` with infer vars, so we don't end up with a type like `Box<$param(0)>` in a context that doesn't have any parameters. But then we can't use `normalize_erasing_late_bound_regions` anymore because that goes though a query that can't deal with infer vars.

Since this is diagnostic-only code that is supposed to check for exactly `-> Self`, I think it's fine to just skip normalizing here, especially since The Correct Way<sup>TM</sup> would involve a probe and make this code even more complicated.

Also, the code here does almost the same thing, and these suggestions can probably be unified in the future: https://github.com/rust-lang/rust/blob/4ca8078d37c53ee4ff8fb32b4453b915116f25b8/compiler/rustc_hir_typeck/src/method/suggest.rs#L2123-L2129

r? ````@compiler-errors````
cc ````@Qelxiros```` -- this should unblock #144420
@rustbot
Copy link
Collaborator

rustbot commented Sep 7, 2025

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

@rust-log-analyzer

This comment has been minimized.

@Qelxiros Qelxiros force-pushed the smart_pointer_try_map branch from 0c65df4 to 59acdbc Compare September 8, 2025 12:44
@rust-log-analyzer

This comment has been minimized.

@Qelxiros Qelxiros force-pushed the smart_pointer_try_map branch from 59acdbc to 2ee0f1d Compare September 8, 2025 14:54
@Qelxiros Qelxiros force-pushed the smart_pointer_try_map branch from 2ee0f1d to dd0846e Compare September 8, 2025 15:01
@rust-log-analyzer

This comment has been minimized.

@Qelxiros Qelxiros force-pushed the smart_pointer_try_map branch from 3c27222 to 375c036 Compare September 18, 2025 12:14
@rust-log-analyzer

This comment has been minimized.

@Qelxiros Qelxiros force-pushed the smart_pointer_try_map branch from 375c036 to 0ee6d47 Compare September 18, 2025 13:23
@rust-log-analyzer

This comment has been minimized.

@Qelxiros Qelxiros force-pushed the smart_pointer_try_map branch from 0ee6d47 to 41ce8ad Compare September 18, 2025 14:28
@Qelxiros
Copy link
Contributor Author

@rustbot label -S-blocked

@rustbot rustbot removed the S-blocked Status: Blocked on something else such as an RFC or other implementation work. label Sep 18, 2025
Copy link
Member

@joboet joboet left a comment

Choose a reason for hiding this comment

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

This looks great! Is it actually still a WIP? Otherwise, maybe change the PR title 😉.

One suggestion, and then I think this is ready to merge.

View changes since this review

@joboet
Copy link
Member

joboet commented Sep 19, 2025

r? joboet

@rustbot rustbot assigned joboet and unassigned thomcc Sep 19, 2025
@Qelxiros Qelxiros force-pushed the smart_pointer_try_map branch from 41ce8ad to cdb8d49 Compare September 19, 2025 15:22
@Qelxiros
Copy link
Contributor Author

The ACP also specifies by-value implementations for UniqueRc and UniqueArc. I can add those to this PR, or I can open a separate one if you think this one is scope creeping too much.

@joboet
Copy link
Member

joboet commented Sep 19, 2025

I don't mind either way.

@Qelxiros Qelxiros changed the title WIP: smart pointer (try_)map smart pointer (try_)map Sep 22, 2025
@rust-log-analyzer

This comment has been minimized.

@Qelxiros Qelxiros force-pushed the smart_pointer_try_map branch from 91cc3b0 to 88ac38e Compare September 22, 2025 14:56
/// an `Rc`.
///
/// Note: this is an associated function, which means that you have
/// to call it as `Rc::map(&r, f)` instead of `r.map(f)`. This
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
/// to call it as `Rc::map(&r, f)` instead of `r.map(f)`. This
/// to call it as `Rc::map(r, f)` instead of `r.map(f)`. This

/// result is returned, also in an `Rc`.
///
/// Note: this is an associated function, which means that you have
/// to call it as `Rc::try_map(&r, f)` instead of `r.try_map(f)`. This
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
/// to call it as `Rc::try_map(&r, f)` instead of `r.try_map(f)`. This
/// to call it as `Rc::try_map(r, f)` instead of `r.try_map(f)`. This

/// also in a `UniqueRc`.
///
/// Note: this is an associated function, which means that you have
/// to call it as `UniqueRc::map(&u, f)` instead of `u.map(f)`. This
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
/// to call it as `UniqueRc::map(&u, f)` instead of `u.map(f)`. This
/// to call it as `UniqueRc::map(u, f)` instead of `u.map(f)`. This

let this = ManuallyDrop::new(this);
let val: T = unsafe { ptr::read(&**this) };

this.inner().dec_strong();
Copy link
Member

Choose a reason for hiding this comment

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

The strong count of a UniqueRc is already zero.

Comment on lines +4603 to +4604
// We know there's only one strong reference, so the ordering doesn't matter.
this.inner().strong.fetch_sub(1, Relaxed);
Copy link
Member

Choose a reason for hiding this comment

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

Same here: there is no strong reference.

@rustbot rustbot 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 Sep 25, 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-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants