-
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
Add a derive! macro to utilise deriving sugar outside Struct/Enum definition #12409
Comments
This is an interesting idea, but I suspect that the reason that E.g. in your example of I'll leave this open because I think some discussion might come up on how else to deal with |
@pnkfelix is correct. |
Some notes: If the conditional attribute is the only concern here, one can use the following macro tricks: macro_rules! define_CovariantType(
($($a:attr)*) => (
#[lang="covariant_type"]
$($a)*
pub struct CovariantType<T>;
)
)
#[cfg(with_alloc)] define_CovariantType!(#[deriving(Eq,Clone)])
#[cfg(not(with_alloc))] define_CovariantType!() |
The other case this might have been useful is impl for objects defined in another crate and re-exported (e.g. prim). Pity is isn't going to work.
|
fix overflow during type inference for tuple struct patterns The following code causes integer overflow during type inference for (malformed) tuple struct patterns. ```rust struct S(usize); let S(.., a, b) = S(1); ``` It has been panicking only in debug builds, and working in a way in release builds but it was inconsistent with type inference for tuple patterns: ```rust struct S(usize); let S(.., a, b) = S(1); // a -> unknown, b -> usize let (.., a, b) = (1,); // a -> usize, b -> unknown ``` With this PR, the overflow no longer happens by utilizing `saturating_sub()` like in other places and type inference for tuple struct patterns is in line with that for tuple patterns.
…ors, r=Alexendoo [`identity_op`]: Fix duplicate diagnostics Relates to rust-lang#12379 In the `identity_op` lint, the following diagnostic was emitted two times ``` --> tests/ui/identity_op.rs:156:5 | LL | 1 * 1; | ^^^^^ help: consider reducing it to: `1` | ``` because both of the left operand and the right operand are the identity element of the multiplication. This PR fixes the issue so that if a diagnostic is created for an operand, the check of the other operand will be skipped. It's fine because the result is always the same in the affected operators. --- changelog: [`identity_op`]: Fix duplicate diagnostics
Not sure if this is the correct solution, but I'm looking at untangling libstd so it can be built freestanding.
The deriving syntax is good, but if you want to make part of it conditional you can't. Looking at #11968, Eq and Clone have to be done with the impl written out in full, be easier to do
derive!(marker::CovariantType<T>, (Eq, Clone))
And if libprim is replaced with #[cfg] tags, you can do
Or maybe these should just be written out in full?
The text was updated successfully, but these errors were encountered: