-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
ICE: rustdoc: Tried to get crate index of builtin macros crate #61804
Comments
Looks like the failure is in an older version of Minimal reproduction: //! [cfg]
Looks like it's trying to treat |
Thanks, I'll try to update! This might be worth fixing in rustdoc though. |
Yeah, i'm investigating how we'd fix this in rustdoc. |
I've opened #61916 to start resolving intra-doc links to builtin macros. |
I just reproduced this today on nightly with Windows 10. No issue on stable. |
Fixed in #62086. |
Define built-in macros through libcore This PR defines built-in macros through libcore using a scheme similar to lang items (attribute `#[rustc_builtin_macro]`). All the macro properties (stability, visibility, etc.) are taken from the source code in libcore, with exception of the expander function transforming input tokens/AST into output tokens/AST, which is still provided by the compiler. The macros are made available to user code through the standard library prelude (`{core,std}::prelude::v1`), so they are still always in scope. As a result **built-in macros now have stable absolute addresses in the library**, like `core::prelude::v1::line!()`, this is an insta-stable change. Right now `prelude::v1` is the only publicly available absolute address for these macros, but eventually they can be moved into more appropriate locations with library team approval (e.g. `Clone` derive -> `core::clone::Clone`). Now when built-in macros have canonical definitions they can be imported or reexported without issues (rust-lang#61687). Other changes: - You can now define a derive macro with a name matching one of the built-in derives (rust-lang#52269). This was an artificial restriction that could be worked around with import renaming anyway. Known regressions: - Empty library crate with a crate-level `#![test]` attribute no longer compiles without `--test`. Previously it didn't compile *with* `--test` or with the bin crate type. Fixes rust-lang#61687 Fixes rust-lang#61804 r? @eddyb
Define built-in macros through libcore This PR defines built-in macros through libcore using a scheme similar to lang items (attribute `#[rustc_builtin_macro]`). All the macro properties (stability, visibility, etc.) are taken from the source code in libcore, with exception of the expander function transforming input tokens/AST into output tokens/AST, which is still provided by the compiler. The macros are made available to user code through the standard library prelude (`{core,std}::prelude::v1`), so they are still always in scope. As a result **built-in macros now have stable absolute addresses in the library**, like `core::prelude::v1::line!()`, this is an insta-stable change. Right now `prelude::v1` is the only publicly available absolute address for these macros, but eventually they can be moved into more appropriate locations with library team approval (e.g. `Clone` derive -> `core::clone::Clone`). Now when built-in macros have canonical definitions they can be imported or reexported without issues (#61687). Other changes: - You can now define a derive macro with a name matching one of the built-in derives (#52269). This was an artificial restriction that could be worked around with import renaming anyway. Known regressions: - Empty library crate with a crate-level `#![test]` attribute no longer compiles without `--test`. Previously it didn't compile *with* `--test` or with the bin crate type. Fixes #61687 Fixes #61804 r? @eddyb
rust-lang/rust#61804 The bug is fixed in nightly but docs.rs hasn't picked up the fix yet.
Running
cargo doc
on rs-sync runs into an ICE today (CI log).The text was updated successfully, but these errors were encountered: