std::compile_error is missing when adding macro to root main module

[maxammann]

The following program does not compile. Not sure if it should, or if this is a bug of my nightly.

#![feature(custom_inner_attributes, proc_macro_hygiene)]

#![cast_checks::enable]


fn main() {
}

error: cannot find macro `compile_error` in this scope
 --> src/main.rs:2:1
  |
2 | / #![feature(custom_inner_attributes, proc_macro_hygiene)]
3 | |
4 | | #![cast_checks::enable]
5 | |
6 | |
7 | | fn main() {
8 | | }
  | |_^
  |
  = help: consider importing one of these items:
          std::compile_error
          core::compile_error

error[E0601]: `main` function not found in crate `asdf`
 --> src/main.rs:8:2
  |
8 | }
  |  ^ consider adding a `main` function to `src/main.rs`

For more information about this error, try `rustc --explain E0601`.

[smoelius]

I've encountered this too. I don't know the cause or fix, unfortunately.

[smoelius]

Not certain, but I think I may have found the cause: dtolnay/syn#1427

[smoelius]

With #6, one now gets the following error message:

applying `cast_checks::enable` at the crate root is not currently supported

There were a couple of underlying issues. The first was that, when used as an inner attribute at the crate level, cast_checks::enable was trying to parse the entire file as an Item and was failing. The second issue was that, when it failed, the compile_error macro could not be found because the prelude had not yet been processed. (The latter was addressed by dtolnay/syn#1431.)

Anyway, do you think we can close this?

[maxammann]

Yes, sounds good!

Do you think this can work with the crate root in the future? (maybe even recursively)

[smoelius]

Do you think this can work with the crate root in the future? (maybe even recursively)

My impression is that it would require better support from the compiler.

The compiler injects some stuff at the top the crate that looks roughly like this:

#[prelude_import]
use std::prelude::rust_2021::*;
#[macro_use]
extern crate std;

One problem is, when the macro processes the file and leaves those things in place, the compiler complains because it thinks the macro put them there (not the compiler) and it considers those things privileged.

I haven't dug into the issues to understand what still needs to be implemented:

• Tracking issue for custom inner attributes rust-lang/rust#54726
• Tracking issue for procedural macros and "hygiene 2.0" rust-lang/rust#54727

But I agree it would be nice to just use cast_checks::enable once at the crate root.