-
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
Disallow deriving (other than Copy/Clone) on types with unnamed fields #121270
Conversation
rustbot has assigned @michaelwoerister. Use r? to explicitly pick a reviewer |
48d9772
to
c863574
Compare
|
Adds some unfortunate duplicated checks to derives so |
This comment has been minimized.
This comment has been minimized.
…, r=<try> Check for accessing unnamed field in `find_field` Fixes rust-lang#121263 I'm not entirely sure this is the right solution, but it seems to work 😓
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (cc60b4c): comparison URL. Overall result: ❌ regressions - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 640.336s -> 641.792s (0.23%) |
find_field
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have some nitpicks and a suggestion for how we might be able to deduplicate things (iterating through the fields twice to check for unnamed fields).
Perf looks spurious.
Sorry for taking soo long! Thanks for your patience :)
@@ -245,3 +245,9 @@ builtin_macros_unexpected_lit = expected path to a trait, found literal | |||
.other = for example, write `#[derive(Debug)]` for `Debug` | |||
|
|||
builtin_macros_unnameable_test_items = cannot test inner items | |||
|
|||
builtin_macros_unnamed_field_derive = only `Copy` and `Clone` may be derived on structs with unnamed fields |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can leave this message as is but since Clone
can only be derived together with Copy
for now, I feel like we should make this more precise / less confusing if possible. Either dropping and `Clone`
entirely or saying `Copy` and `Clone` with `Copy`
which is a bit awkward I admit. Open to suggestions.
.note = unnamed field | ||
|
||
builtin_macros_unnamed_field_derive_clone = | ||
deriving `Clone` on a type with unnamed fields requires also deriving `Copy` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we also add the note/label unnamed field like in the case above?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
iirc we don't have a better span at this point for the field so I omitted that
@@ -69,6 +70,10 @@ impl Path { | |||
} | |||
} | |||
} | |||
|
|||
pub fn components(&self) -> &[Symbol] { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pub fn components(&self) -> &[Symbol] { | |
pub fn segments(&self) -> &[Symbol] { |
I think we generally use the terminology path segments in the context of Rust paths contrary to filesystem paths which indeed use path components.
if let ast::ItemKind::Struct(struct_def, _) | ast::ItemKind::Union(struct_def, _) = | ||
&item.kind | ||
&& let Some(&trait_name) = self.path.components().last() | ||
&& !(trait_name == sym::Copy || trait_name == sym::Clone) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Theoretically we could move the “#[derive(Clone)]
requires accompanying #[derive(Copy)]
” check here to avoid the duplication, right? Or you do think this “violates the layers of abstraction”? I haven't thought that hard about it.
Ah, but that would lead to us performing more work in the error path since we wouldn't be able to return early in expand_deriving_clone
. However, that should be fine as long as we don't trigger any debug asserts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, one more thing: Could you add a FIXME(unnamed_fields)
(here or in mod clone
depending on the way we go forward) saying that we should permit derive(Clone)
without derive(Copy)
once we can support it, i.e., once struct initialization supports unnamed fields.
LL | #[derive(Debug)] | ||
| ^^^^^ | ||
| | ||
note: unnamed field |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like this should be a label instead of note but it's not that important.
LL | #[derive(Debug)] | ||
| ^^^^^ | ||
| | ||
note: unnamed field |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note: unnamed field | |
note: an unnamed field is specified here |
note: unnamed field | |
note: unnamed field found here |
Not set in stone but you get my point, something more elaborate :) thanks!
Marking this is as blocked / waiting on team. Feature |
@fmease can you please point me to the FCP? Did a quick search and couldn't find it :) |
There's no FCP yet, my comment was a bit imprecise. T-lang has decided to propose an FCP with disposition close in the triage meeting 2024-03-20 (see this section of the minutes, scroll down to Consensus) once @compiler-errors has written up the necessary context for the other T-lang members (arguments for & against |
@rustbot label: +I-lang-nominated This PR that addresses some ICEs arising for the unstable The T-compiler team wants to know the opinion of T-lang of whether (See also the context established by https://hackmd.io/7r0i-EWyR8yO6po2LnS2rA#Tracking-issue-for-RFC-2102-Unnamed-fields-of-struct-and-union-type-rust49804 (where I think there was supposed to be an eventual writeup of the concerns people had with |
We discussed this in the meeting on 2024-06-12 without consensus. Some felt that this was still needed, others first wanted to look for a more minimal approach. We left this for further discussion. |
I don't understand this entire comment thread. Here's the situation: stable Rust compilers ICE, for trivial code, my #131041 is a minimisation of very complicated code that blew up because I erroneously didn't name a field, but this is likely happening to beginners too. Everything else I saw here is a distraction from that very simple but serious problem and has resulted in just not fixing it, for months. |
Fixes #121263
Fixes #121299
Fixes #121161