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

Add a derive! macro to utilise deriving sugar outside Struct/Enum definition #12409

Closed
bharrisau opened this issue Feb 20, 2014 · 4 comments
Closed

Comments

@bharrisau
Copy link
Contributor

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

#[lang="covariant_type"]
pub struct CovariantType<T>;

#[cfg(with_alloc)] derive!(CovariantType<T>, (Eq, Clone))

Or maybe these should just be written out in full?

@pnkfelix
Copy link
Member

This is an interesting idea, but I suspect that the reason that deriving! has to occur where it does in the syntax (immediately above the definition of the item in question) is that the macro machinery does not have the ability to resolve a path. (That is, macro expansion occurs before the resolve step, I think.)

E.g. in your example of derive!(marker::CovariantType<T>, (Eq, Clone)) it does not have the ability to resolve marker::CovariantType<T> to its definition (which it needs to expand into the desired impl being derived).

I'll leave this open because I think some discussion might come up on how else to deal with cfg-conditional derived impls.

@sfackler
Copy link
Member

@pnkfelix is correct.

@lifthrasiir
Copy link
Contributor

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!()

@bharrisau
Copy link
Contributor Author

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.

mod foo {
  struct Bar {
    ....
  }
}

pub use foo:Bar;

derive!(Bar, (Clone))

bors added a commit to rust-lang-ci/rust that referenced this issue Jul 25, 2022
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.
flip1995 pushed a commit to flip1995/rust that referenced this issue Mar 7, 2024
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants