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.

Sign up for GitHub

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

Jump to bottom

The #[pointee] attribute is required even if there is only one generic parameter #129465

Closed
Darksonn opened this issue Aug 23, 2024 · 2 comments · Fixed by #129467
Closed

The #[pointee] attribute is required even if there is only one generic parameter #129465

Darksonn opened this issue Aug 23, 2024 · 2 comments · Fixed by #129467
Assignees
@dingxiangfei2009
Labels
C-bug Category: This is a bug. F-derive_coerce_pointee Feature: RFC 3621's oft-renamed implementation T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Darksonn
Copy link
Contributor

Darksonn commented Aug 23, 2024 •
edited by rustbot
Loading

Currently, the following code triggers a compilation failure.

#![feature(derive_smart_pointer)]
use core::marker::SmartPointer;

#[repr(transparent)]
#[derive(SmartPointer)]
struct MyArc<T: ?Sized> {
    inner: *mut T,
}
error: At least one generic type should be designated as `#[pointee]` in order to derive `SmartPointer` traits
 --> src/lib.rs:5:10
  |
5 | #[derive(SmartPointer)]
  |          ^^^^^^^^^^^^
  |
  = note: this error originates in the derive macro `SmartPointer` (in Nightly builds, run with -Z macro-backtrace for more info)

However, the RFC says that specifying #[pointee] when the struct has only one type parameter is allowed, but not required.

See also this patch on the LKML.

Tracking issue: #123430
cc @dingxiangfei2009
@rustbot rustbot added needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. F-derive_coerce_pointee Feature: RFC 3621's oft-renamed implementation labels Aug 23, 2024
Darksonn added a commit to Darksonn/linux that referenced this issue Aug 23, 2024
@Darksonn
rust: experiment with #[derive(SmartPointer)]
572e93f 
I am sending this RFC patch to share my experience with using the new
`#[derive(SmartPointer)]` feature [1] with our custom smart pointers.
The feature is being added so that the kernel can stop using the
unstable dispatch_from_dyn and unsize features.

In general, the feature appears to work. As can be seen in the change to
`rust_minimal.rs`, it is possible to use `Arc` together with a dynamic
trait object, and the trait object is object safe even though it uses
the custom smart pointer as a self parameter.

I did run into one nit, which is that `Arc` requires the `#[pointee]`
annotation even though there's only one generic paramter. I filed an
issue [2] about this.

Link: https://rust-lang.github.io/rfcs/3621-derive-smart-pointer.html [1]
Link: rust-lang/rust#129465 [2]
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Darksonn added a commit to Darksonn/linux that referenced this issue Aug 23, 2024
@Darksonn
rust: experiment with #[derive(SmartPointer)]
56c0c1e 
I am sending this RFC patch to share my experience with using the new
`#[derive(SmartPointer)]` feature [1] with our custom smart pointers.
The feature is being added so that the kernel can stop using the
unstable dispatch_from_dyn and unsize features.

In general, the feature appears to work. As can be seen in the change to
`rust_minimal.rs`, it is possible to use `Arc` together with a dynamic
trait object, and the trait object is object safe even though it uses
the custom smart pointer as a self parameter.

I did run into one nit, which is that `Arc` requires the `#[pointee]`
annotation even though there's only one generic paramter. I filed an
issue [2] about this.

Link: https://rust-lang.github.io/rfcs/3621-derive-smart-pointer.html [1]
Link: rust-lang/rust#129465 [2]
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Darksonn added a commit to Darksonn/linux that referenced this issue Aug 23, 2024
@Darksonn
rust: experiment with #[derive(SmartPointer)]
eeddb87 
I am sending this RFC patch to share my experience with using the new
`#[derive(SmartPointer)]` feature [1] with our custom smart pointers.
The feature is being added so that the kernel can stop using the
unstable dispatch_from_dyn and unsize features.

In general, the feature appears to work. As can be seen in the change to
`rust_minimal.rs`, it is possible to use `Arc` together with a dynamic
trait object, and the trait object is object safe even though it uses
the custom smart pointer as a self parameter.

I did run into one nit, which is that `Arc` requires the `#[pointee]`
annotation even though there's only one generic paramter. I filed an
issue [2] about this.

Link: https://rust-lang.github.io/rfcs/3621-derive-smart-pointer.html [1]
Link: rust-lang/rust#129465 [2]
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Darksonn added a commit to Darksonn/linux that referenced this issue Aug 23, 2024
@Darksonn
rust: experiment with #[derive(SmartPointer)]
74f615c 
I am sending this RFC patch to share my experience with using the new
`#[derive(SmartPointer)]` feature [1] with our custom smart pointers.
The feature is being added so that the kernel can stop using the
unstable dispatch_from_dyn and unsize features.

In general, the feature appears to work. As can be seen in the change to
`rust_minimal.rs`, it is possible to use `Arc` together with a dynamic
trait object, and the trait object is object safe even though it uses
the custom smart pointer as a self parameter.

I did run into one nit, which is that `Arc` requires the `#[pointee]`
annotation even though there's only one generic paramter. I filed an
issue [2] about this.

Link: https://rust-lang.github.io/rfcs/3621-derive-smart-pointer.html [1]
Link: rust-lang/rust#129465 [2]
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
@ojeda ojeda mentioned this issue Aug 23, 2024
Open
89 tasks
@dingxiangfei2009
Copy link
Contributor

@rustbot claim

@Darksonn
Copy link
Contributor Author

Oh, also, the error message says "At least one generic" but it's not valid to have several pointees.

@dingxiangfei2009 dingxiangfei2009 mentioned this issue Aug 23, 2024
Merged
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this issue Aug 26, 2024
@Darksonn @intel-lab-lkp
rust: experiment with #[derive(SmartPointer)]
e8b105c 
I am sending this RFC patch to share my experience with using the new
`#[derive(SmartPointer)]` feature [1] with our custom smart pointers.
The feature is being added so that the kernel can stop using the
unstable dispatch_from_dyn and unsize features.

In general, the feature appears to work. As can be seen in the change to
`rust_minimal.rs`, it is possible to use `Arc` together with a dynamic
trait object, and the trait object is object safe even though it uses
the custom smart pointer as a self parameter.

I did run into one nit, which is that `Arc` requires the `#[pointee]`
annotation even though there's only one generic paramter. I filed an
issue [2] about this.

Link: https://rust-lang.github.io/rfcs/3621-derive-smart-pointer.html [1]
Link: rust-lang/rust#129465 [2]
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Aug 28, 2024
@matthiaskrgr
Rollup merge of rust-lang#129467 - dingxiangfei2009:smart-pointer-rel…
4168c39 
…ax-pointee, r=compiler-errors

derive(SmartPointer): assume pointee from the single generic and better error messages

Fix rust-lang#129465

Actually RFC says that `#[pointee]` can be inferred when there is no ambiguity, or there is only one generic type parameter so to say.

cc `@Darksonn`

r? `@compiler-errors`
workingjubilee added a commit to workingjubilee/rustc that referenced this issue Aug 29, 2024
@workingjubilee
Rollup merge of rust-lang#129467 - dingxiangfei2009:smart-pointer-rel…
c05e451 
…ax-pointee, r=compiler-errors

derive(SmartPointer): assume pointee from the single generic and better error messages

Fix rust-lang#129465

Actually RFC says that `#[pointee]` can be inferred when there is no ambiguity, or there is only one generic type parameter so to say.

cc ``@Darksonn``

r? ``@compiler-errors``
@bors bors closed this as completed in d2418cb Aug 29, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Aug 29, 2024
@rust-timer
Unrolled build for rust-lang#129467
52c9ca0 
Rollup merge of rust-lang#129467 - dingxiangfei2009:smart-pointer-relax-pointee, r=compiler-errors

derive(SmartPointer): assume pointee from the single generic and better error messages

Fix rust-lang#129465

Actually RFC says that `#[pointee]` can be inferred when there is no ambiguity, or there is only one generic type parameter so to say.

cc ```@Darksonn```

r? ```@compiler-errors```
@saethlin saethlin added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-bug Category: This is a bug. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Aug 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@dingxiangfei2009 dingxiangfei2009

Labels
C-bug Category: This is a bug. F-derive_coerce_pointee Feature: RFC 3621's oft-renamed implementation T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
4 participants
@Darksonn @dingxiangfei2009 @saethlin @rustbot