-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Deriving may want to ignore marker fields #14268
Comments
There's no way to do this in general, Implementing more traits for the markers would work. |
Every single derivable trait would have to be implemented on the markers (except for For example, a struct with a marker is unlikely to find Similarly, including the field in
Crud, looks like you're right. Deriving can see the path to the type, but I guess it can't actually get any info about it beyond that path. An alternative would be an attribute on the field that says it should be skipped for derivings. Although again, it would want to be ignored for Clone, and I'm not sure how to handle #[deriving(Show)]
struct Foo {
x: int,
#[deriving(skip)]
nocopy: ::std::kinds::marker::NoCopy
} We could even use |
An attribute to exclude a field sounds like a more useful solution, and also easily allows customization for other use cases. |
@Kimundi I have a PR #14219 that allows for customizing of Perhaps we could re-use the |
I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized. This issue has been moved to the RFCs repo: rust-lang/rfcs#726 |
internal: Switch to `expected.assert_eq` for `ide` tests This PR switches from `assert_debug_eq` to `assert_eq` and only compares parts of the result and not the whole. The aim is to only compare parts which are relevant to the test and also make it more readable. Part of rust-lang#14268. ## Questions - [x] Can I use `Vec`? If not, what is the alternative? I assume I cannot because of: https://github.com/rust-lang/rust-analyzer/blob/c3a00b5468576de4e39adc8fa5ceae35a0024e49/docs/dev/architecture.md?plain=1#L413 - [x] Should I group it by file, as proposed by Lukas? ``` file_id 1: source_file_edits: - Indel { insert: "foo2", delete: 4..7 } file_id 2: file_system_edits: MoveFile AnchoredPathBuf { anchor: FileId(2), path: "foo2.rs", } ``` - [x] Is it okay to ignore `CreateFile` events? They do not have a FileId, which would be problematic, but they do not occur in the existing tests, so I marked them as `unreachable!()` so far.
Marker fields are used to provide extra information about types, including opting out of
Copy
,Send
, andShare
bounds. However, the presence of a marker field can prevent the ability to#[derive]
traits for that type. For example,core::kinds::marker::NoCopy
only implementsClone
andEq
(according to rustdoc; I am unsure if there are any libstd traits it implements because rustdoc doesn't show cross-crate traits). This means that any struct with aNoCopy
field cannot e.g. deriveShow
, orOrd
, or other useful traits.I think the right solution here is to simply not consider the marker fields when deriving traits, with the only exception being
Clone
. Every other trait should just pretend that field doesn't exist.The text was updated successfully, but these errors were encountered: