Skip to content

Imports/reexports of built-in macros are not supported #61687

Closed
@petrochenkov

Description

@petrochenkov
Contributor
use column; // error: cannot import a built-in macro

fn main() {}

The reason behind this error is that if you import something with a DefId, that DefId should be supported by all stages of compilation (metadata emitting specifically), but built-in macros don't have such a DefId.

The crate ID in their DefId has special value CrateNum::BuiltinMacros that is supported only inside rustc_resolve and causes ICEs every time it leaves it.

Activity

added
A-macrosArea: All kinds of macros (custom derive, macro_rules!, proc macros, ..)
A-resolveArea: Name/path resolution done by `rustc_resolve` specifically
C-bugCategory: This is a bug.
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
on Jun 9, 2019
petrochenkov

petrochenkov commented on Jun 9, 2019

@petrochenkov
ContributorAuthor

Possible fix 1.

Use LOCAL_CRATE as a CrateNum in built-in macros' DefIds.

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 LOCAL_CRATE will mean that each crate reexporting built-in macros will reexport it's own different version (with a separate DefId).
This is not correct and observable through import conflicts (imports of the same macro will conflict while they shouldn't).
This can perhaps be fixed by changing DefIds (resetting crate num to LOCAL_CRATE) on the fly during metadata loading (?). Not sure.

petrochenkov

petrochenkov commented on Jun 9, 2019

@petrochenkov
ContributorAuthor

Possible fix 2.

Introduce a special CrateNum for things defined by the language rather than any crate and support it through the whole compilation (aka CrateNum::BuiltinMacros done right).

Built-in types could potentially use it as well if it becomes necessary for them to have DefIds.

self-assigned this
on Jun 9, 2019
petrochenkov

petrochenkov commented on Jun 9, 2019

@petrochenkov
ContributorAuthor

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. ::std::column!()) from other macros (the __rust_unstable_column!() problem) even without having stable def-site hygiene in the language.

petrochenkov

petrochenkov commented on Jun 15, 2019

@petrochenkov
ContributorAuthor

Fixed in #62086

added a commit that references this issue on Jul 26, 2019

Rollup merge of rust-lang#62086 - petrochenkov:builtout, r=eddyb

c5c5534
added a commit that references this issue on Jul 26, 2019

Auto merge of #62086 - petrochenkov:builtout, r=eddyb

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

A-macrosArea: All kinds of macros (custom derive, macro_rules!, proc macros, ..)A-resolveArea: Name/path resolution done by `rustc_resolve` specificallyC-bugCategory: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.T-langRelevant to the language team

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

    Participants

    @Centril@jonas-schievink@petrochenkov

    Issue actions

      Imports/reexports of built-in macros are not supported · Issue #61687 · rust-lang/rust