-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Imports/reexports of built-in macros are not supported #61687
Comments
Possible fix 1. Use Built-in macros have fixed def-indices, so we should be able to recognize a built-in macro when loading metadata from other crate and thus know how to expand it. Using |
Possible fix 2. Introduce a special Built-in types could potentially use it as well if it becomes necessary for them to have |
The primary motivation for fixing this is reexporting built-in macros from the standard library. This way those macros will have a reliable way to call them (e.g. |
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
The reason behind this error is that if you import something with a
DefId
, thatDefId
should be supported by all stages of compilation (metadata emitting specifically), but built-in macros don't have such aDefId
.The crate ID in their
DefId
has special valueCrateNum::BuiltinMacros
that is supported only inside rustc_resolve and causes ICEs every time it leaves it.The text was updated successfully, but these errors were encountered: