juici / int-enum-rs Goto Github PK

Why it is not #[derive(int_enum::int_enum)] instead of #[int_enum::int_enum]? Does it require feature inaccessible to derive macros?

I there a chance that IntEnum can be implemented without expanding to a constant?

The crate should instead either not emit a constant at all for this, or give the constant the blank name _, which we somewhat support.

Full description - rust-lang/rust-analyzer#13347 (comment)

I have an enum that looks like:

#[repr(u16)]
#[derive(Clone, Copy, int_enum::IntEnum)]
enum Controls {
    DpadUp     = 1<<0,
    DpadDown   = 1<<1,
    DpadLeft   = 1<<2,
    DpadRight  = 1<<3,
    FaceA      = 1<<4,
    FaceB      = 1<<5,
    ...[snip]
}

1 entry for each bit of a u16. IntEnum chokes:

error: expected one of `...`, `..=`, `..`, `=>`, `if`, or `|`, found `<<`
  --> src/main.rs:35:19
   |
35 |     DpadUp     = 1<<0,
   |                   ^^ expected one of `...`, `..=`, `..`, `=>`, `if`, or `|`

error: proc-macro derive produced unparsable tokens
  --> src/main.rs:33:23
   |
33 | #[derive(Clone, Copy, int_enum::IntEnum)]
   |           

The normal enum syntax does support the bitshift expressions here. Would it be possible for int_enum to support simple arithmetic in the assignment position?

The CI is failing due to linting issues: https://github.com/Juici/int-enum-rs/actions/runs/7938582606/job/21677556529#step:4:48

badges/shields#8671

SpanExt defines a method:

fn end(&self) -> Span;

And implements it on Span. However, proc-marco2 with feature span-locations also defines a method on Span:

    #[cfg(span_locations)]
    #[cfg_attr(doc_cfg, doc(cfg(feature = "span-locations")))]
    pub fn end(&self) -> LineColumn {
        self.inner.end()
    }

When calling end on a Span object with that feature enabled the above method takes precedence. This breaks code in an ast module where it defines:

diag = diag.span_error(v.span().end(), "missing discriminant");

Since the SpanExt is in scope the intention was for .end() to return a Span object which works since it implements MultiSpan required by span_error. With span-locations enabled It returns a LineColumn which does not implement MultiSpan:

   --> int-enum-1.0.0/src/ast.rs:120:36
    |
120 |             diag = diag.span_error(v.span().end(), "missing discriminant");
    |                         ---------- ^^^^^^^^^^^^^^ the trait `proc_macro2_diagnostics::diagnostic::MultiSpan` is not implemented for `LineColumn`
    |                         |
    |                         required by a bound introduced by this call
    |
    = help: the following other types implement trait `proc_macro2_diagnostics::diagnostic::MultiSpan`:
              proc_macro2::Span
              Vec<proc_macro2::Span>
              &'a [proc_macro2::Span]
note: required by a bound in `proc_macro2_diagnostics::Diagnostic::span_error`

The solution would be to refer to the trait explicitly:

diag = diag.span_error(<Span as SpanExt>::end(&v.span()), "missing discriminant");

The macro is panicking when emitting diagnostics on nightly.

error: proc-macro derive panicked
 --> tests/ui/missing_discriminant.rs:4:23
  |
4 | #[derive(Clone, Copy, IntEnum)]
  |                       ^^^^^^^
  |
  = help: message: assertion failed: child.level.can_be_top_or_sub().1

This is caused by a compiler change here https://github.com/rust-lang/rust/blob/59e0bc2de7134a2d88e9c14db32884e631e90373/compiler/rustc_errors/src/emitter.rs#L2119.

The only levels that can be used for sub-diagnostics emitted by proc-macros are now Warning, Note, and Help.