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

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

Merged
merged 1 commit into from
Aug 29, 2024

Conversation

dingxiangfei2009
Copy link
Contributor

Fix #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

@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 Aug 23, 2024
@Darksonn
Copy link
Contributor

@rustbot label F-derive_smart_pointer

@rustbot rustbot added the F-derive_smart_pointer `#![feature(derive_smart_pointer)]` label Aug 23, 2024
Comment on lines 86 to 106
if p.attrs().iter().any(|attr| attr.has_name(sym::pointee)) {
if pointee_param.is_some() {
multiple_pointee_diag.push(cx.dcx().struct_span_err(
p.span(),
"`SmartPointer` can only admit one type as pointee",
));
} else {
pointee_param = Some(idx);
match pointee_param {
PointeeChoice::Assumed(_)
| PointeeChoice::Ambiguous
| PointeeChoice::None => {
pointee_param = PointeeChoice::Exactly(idx, p.span())
}
PointeeChoice::Exactly(_, another) => {
pointee_param = PointeeChoice::MultiplePointeeChoice(another, p.span())
}
PointeeChoice::MultiplePointeeChoice(_, _) => {}
}
} else {
match pointee_param {
PointeeChoice::None => pointee_param = PointeeChoice::Assumed(idx),
PointeeChoice::Assumed(_) | PointeeChoice::Ambiguous => {
pointee_param = PointeeChoice::Ambiguous
}
PointeeChoice::Exactly(_, _)
| PointeeChoice::MultiplePointeeChoice(_, _) => {}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if we can simplify these map operations with side effects by iterating multiple times. For example: (untested)

let self_params = generics
    .params
    .iter()
    .enumerate()
    .map(|(idx, p)| match p.kind {
        GenericParamKind::Lifetime => GenericArg::Lifetime(cx.lifetime(p.span(), p.ident)),
        GenericParamKind::Type { .. } => GenericArg::Type(cx.ty_ident(p.span(), p.ident)),
        GenericParamKind::Const { .. } => GenericArg::Const(cx.const_ident(p.span(), p.ident)),
    })
    .collect::<Vec<_>>();

let all_type_params = generics
    .params
    .iter()
    .enumerate()
    .filter_map(|(idx, p)| match p.kind {
        GenericParamKind::Type { .. } => Some((idx, p.span())),
        _ => None,
    })
    .collect::<Vec<(usize, Span)>>();

let pointee_params = generics
    .params
    .iter()
    .enumerate()
    .filter_map(|(idx, p)| match p.kind {
        GenericParamKind::Type { .. } if p.attrs().iter().any(|attr| attr.has_name(sym::pointee)) => Some((idx, p.span())),
        _ => None,
    })
    .collect::<Vec<(usize, Span)>>();

let pointee_param = match (pointee_params.as_slice(), all_type_params.as_slice()) {
    ([(idx, _span)], _) => idx,
    ([], [(idx, _span)]) => idx,
    ([], []) => {
        cx.dcx().struct_span_err(span, "`SmartPointer` requires a generic parameter").emit();
        return;
    }
    ([], _) => {
        let all_type_spans = all_type_params.into_iter().map(|(idx,span)| span).collect();
        cx.dcx().struct_span_err(all_type_spans, "you must use `#[pointee]` to specify which parameter is the `SmartPointer` pointee").emit();
        return;
    }
    (_, _) => {
        let pointee_spans = pointee_params.into_iter().map(|(idx,span)| span).collect();
        cx.dcx().struct_span_err(pointee_spans, "you can only use `#[pointee]` once").emit();
        return;
    }
};

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Applied with slight adaptation

So now we one pass through the generics to get ourserlves the self_params. One more pass through the iterator is used to collect only the type parameters.

  • If we find zero type parameters, err with diagnosis
  • If we find exactly one type parameter, use it as #[pointee]
  • Otherwise, filter through type parameters on whether there is #[pointee] designation and err when more than one such parameters are found

(None, _) => {
cx.dcx().struct_span_err(
span,
"Exactly one generic parameters when there are at least two generic type parameters \
Copy link
Member

Choose a reason for hiding this comment

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

diagnostics should not be capitalized

also this message could be tweaked:

exactly one generic type parameter must be marked as #[pointee] to derive SmartPointer traits

Copy link
Member

Choose a reason for hiding this comment

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

also, there is no test for this message?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oops. Added.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I forgot to add the hunk with the updated message as per your suggestion. It is checked in now.

}
let pointee_param_idx = if type_params.len() == 1 {
Copy link
Member

Choose a reason for hiding this comment

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

could you special case the == 0 case?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Applied. Moved the check above into here.

cx.dcx()
.struct_span_err(
vec![one, another],
"`SmartPointer` can only admit one type as pointee",
Copy link
Member

Choose a reason for hiding this comment

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

Can you adjust this message?

only one type parameter can be marked as #[pointee] when deriving SmartPointer traits

sounds more natural that way

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Applied

@compiler-errors
Copy link
Member

@rustbot author

@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 Aug 26, 2024
@dingxiangfei2009
Copy link
Contributor Author

@rustbot ready

  • Ran through the test and made sure that all diagnostic messages appeared, or have been used, at least once
  • Applied suggestions on wording

@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 Aug 28, 2024
@compiler-errors
Copy link
Member

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Aug 28, 2024

📌 Commit 3914835 has been approved by compiler-errors

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 28, 2024
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Aug 28, 2024
…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 added a commit to rust-lang-ci/rust that referenced this pull request Aug 28, 2024
…iaskrgr

Rollup of 11 pull requests

Successful merges:

 - rust-lang#128166 (Improved `checked_isqrt` and `isqrt` methods)
 - rust-lang#129170 (Add an ability to convert between `Span` and `visit::Location`)
 - rust-lang#129366 (linker: Synchronize native library search in rustc and linker)
 - rust-lang#129467 (derive(SmartPointer): assume pointee from the single generic and better error messages)
 - rust-lang#129494 (format code in tests/ui/threads-sendsync)
 - rust-lang#129527 (Don't use `TyKind` in a lint)
 - rust-lang#129617 (Update books)
 - rust-lang#129673 (Add fmt::Debug to sync::Weak<T, A>)
 - rust-lang#129683 (copysign with sign being a NaN can have non-portable results)
 - rust-lang#129689 (Move `'tcx` lifetime off of impl and onto methods for `CrateMetadataRef`)
 - rust-lang#129695 (Fix path to run clippy on rustdoc)

r? `@ghost`
`@rustbot` modify labels: rollup
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Aug 29, 2024
…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 added a commit to rust-lang-ci/rust that referenced this pull request Aug 29, 2024
…kingjubilee

Rollup of 14 pull requests

Successful merges:

 - rust-lang#128192 (rustc_target: Add various aarch64 features)
 - rust-lang#129170 (Add an ability to convert between `Span` and `visit::Location`)
 - rust-lang#129343 (Emit specific message for time<=0.3.35)
 - rust-lang#129378 (Clean up cfg-gating of ProcessPrng extern)
 - rust-lang#129401 (Partially stabilize `feature(new_uninit)`)
 - rust-lang#129467 (derive(SmartPointer): assume pointee from the single generic and better error messages)
 - rust-lang#129494 (format code in tests/ui/threads-sendsync)
 - rust-lang#129617 (Update books)
 - rust-lang#129673 (Add fmt::Debug to sync::Weak<T, A>)
 - rust-lang#129683 (copysign with sign being a NaN can have non-portable results)
 - rust-lang#129689 (Move `'tcx` lifetime off of impl and onto methods for `CrateMetadataRef`)
 - rust-lang#129695 (Fix path to run clippy on rustdoc)
 - rust-lang#129712 (Correct trusty targets to be tier 3)
 - rust-lang#129715 (Update `compiler_builtins` to `0.1.123`)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit d2418cb into rust-lang:master Aug 29, 2024
6 checks passed
@rustbot rustbot added this to the 1.82.0 milestone Aug 29, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Aug 29, 2024
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```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F-derive_smart_pointer `#![feature(derive_smart_pointer)]` S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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.

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