The compiler should complain about unknown features before complaining about missing crate attributes

[wooster0]

Given the following code:

#![feature(const_raw_ptr_dere)] // Note the missing f
#![feature(const_mut_refs)]

struct A;

const fn a() -> &'static mut A {
    unsafe { &mut *(0x11 as *mut A) }
}

The current output is:

error[E0658]: dereferencing raw pointers in constant functions is unstable
 --> src/lib.rs:7:14
  |
7 |     unsafe { &mut *(0x11 as *mut A) }
  |              ^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: see issue #51911 <https://github.com/rust-lang/rust/issues/51911> for more information
  = help: add `#![feature(const_raw_ptr_deref)]` to the crate attributes to enable

error: aborting due to previous error

For more information about this error, try `rustc --explain E0658`.
error: could not compile `playground`

To learn more, run the command again with --verbose.

Ideally the output should look like:

error[E0635]: unknown feature `const_raw_ptr_dere`
 --> src/lib.rs:1:12
  |
1 | #![feature(const_raw_ptr_dere)]
  |            ^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0635`.
error: could not compile `playground`

To learn more, run the command again with --verbose.

I think it would be much more helpful if the compiler complained about the unknown feature before it complains about me needing to add the feature. This led to a very confusing moment when I was missing the s at the end of custom_test_frameworks which the compiler didn't tell me about. That, or maybe it should just display both of those errors at once?
What I'm describing here is rather specific but maybe this can be made more general so that the compiler always rants about unknown attributes first? Not sure how feasible that is or how much sense that makes in other cases.

[eggyal]

maybe this can be made more general so that the compiler always rants about unknown attributes first

Unknown attributes already trigger cannot find attribute errors. The problem here is that the feature attribute is known, but it didn't complain about an unrecognised token amongst its arguments.

[wooster0]

Oh, right, I meant unknown attribute arguments, not unknown attribute.

[eggyal]

That's down to the implementation of each individual attribute, though... they receive an opaque token stream and can do whatever they want (or don't want) with it.

[eggyal]

Duplicate of #44232