Repository navigation
restore the old behavior for derive(Default) on fieldless types - #164114
Conversation
|
Changes to the code generated for builtin derived traits. cc @nnethercote |
| extern crate struct_to_enum; | ||
| use struct_to_enum::*; | ||
|
|
||
| #[derive(Clone, Copy, Default, Hash, PartialEq, Eq, PartialOrd, Ord, Debug)] |
There was a problem hiding this comment.
This is also interesting: the Default derive produces an error on stable (expected struct, variant or union type, found enum Spooky), on beta (the Self constructor can only be used with tuple or unit structs), but #163863 caused it to compile. After this PR, it will fail again as on stable. Is this okay?
There was a problem hiding this comment.
We shouldn't make any "this code now starts compiling" changes without going through some kind of process, so this is a bug in its own right.
Can you double check none such things slipped through in your other builtin macro refactorings? I remember you writing a series of prs.
There was a problem hiding this comment.
Matching stable sounds reasonable to me.
|
Thanks for writing the nice tests. At least this reversion is a small one. @bors r+ rollup |
…uwer Rollup of 8 pull requests Successful merges: - #163258 (Move `rustc_middle::ty::Const` to `rustc_type_ir` Part 2) - #164173 (don't drop `AnyOpaqueHasInferAsHidden` when merging with `OpaqueInStorageOrAnyOpaqueHasInferAsHidden`) - #160230 (CFI: Cover each InstanceKind explicitly) - #163713 (codegen Propagate reported errors from ABI checks) - #164205 (cg_llvm: Assorted cleanups to LLVM diagnostic handling) - #164114 (restore the old behavior for `derive(Default)` on fieldless types) - #164127 (core: Ignore explicit_tail_calls doc tests on PowerPC) - #164204 (explicitly mark next-solver ICE in test suite)
Rollup merge of #164114 - cyrgani:attrs-vs-default, r=nnethercote restore the old behavior for `derive(Default)` on fieldless types Fixes #164078. This restores the behavior before #161867, where `derive(Default)` always generated `Unit {}` for any struct without fields, which some (arguably wrong) code depends on. r? @nnethercote
|
I think this needs to be backported as well? |
Fixes #164078.
This restores the behavior before #161867, where
derive(Default)always generatedUnit {}for any struct without fields, which some (arguably wrong) code depends on.r? @nnethercote