resolve/metadata: Stop encoding macros as reexports #91795

petrochenkov · 2021-12-11T15:38:44Z

hir: Do not introduce dummy type names for `extern` blocks in def paths Use a separate nameless `DefPathData` variant instead. Extracted from rust-lang#91795.

petrochenkov · 2021-12-24T14:31:44Z

Blocked on #92034 and #92086.

Remove effect of `#[no_link]` attribute on name resolution Previously it hid all non-macro names from other crates. This has no relation to linking and can change name resolution behavior in some cases (e.g. glob conflicts), in addition to just producing the "unresolved name" errors. I can kind of understand the possible reasoning behind the current behavior - if you can use names from a `no_link` crates then you can use, for example, functions too, but whether it will actually work or produce link-time errors will depend on random factors like inliner behavior. (^^^ This is not the actual reason why the current behavior exist, I've looked through git history and it's mostly accidental.) I think this risk is ok for such an obscure attribute, and we don't need to specifically prevent use of non-macro items from such crates. (I'm not actually sure why would anyone use `#[no_link]` on a crate, even if it's macro only, if you aware of any use cases, please share. IIRC, at some point it was used for crates implementing custom derives - the now removed legacy ones, not the current proc macros.) Extracted from rust-lang#91795.

petrochenkov · 2022-02-04T03:45:14Z

I understand that this PR resolves the ambiguity between normal exports and macro_rules re-export by adding a macro_rules flag to metadata to distinguish between the two. In that case, I'm not sure to understand what is the benefit compared to the former setup.

Previously macros were encoded as both items and reexports, but the item versions were ignored during decoding to avoid duplication.
Now they are only encoded as items are decoded as items, which is more right because macros are not reexports and it was strange to encode them as such, and also this allows to just encode less data.

petrochenkov · 2022-02-04T03:49:10Z

For performance it would be optimal to use two structures:

// This struct is used during decoding and unifies both proper items and reexports
struct ModChild {
    pub ident: Ident,
    pub res: Res<!>,
    pub vis: ty::Visibility,
    pub span: Span,
    pub macro_rules: bool,
}

// This structure is used for encoding the reexport table, `macro_rules` is always false by definition
pub struct Reexport {
    pub ident: Ident,
    pub res: Res<!>,
    pub vis: ty::Visibility,
    pub span: Span,
}

, but I just didn't want to introduce more entities.
I can try it in a separate PR, but the perf benefits from not encoding this extra bool will probably be lost in noise, so it's likely not worth it.

petrochenkov · 2022-02-04T16:39:16Z

Updated.

cjgillot · 2022-02-24T16:03:31Z

Sorry for the delay.
r=me once rebased.

…-in macros Previously it always returned `MacroKind::Bang` while some of those macros are actually attributes and derives

To make the `macro_rules` flag more readily available without decoding everything else

petrochenkov · 2022-02-24T20:39:43Z

@bors r=cjgillot

bors · 2022-02-24T20:39:45Z

📌 Commit b91ec30 has been approved by cjgillot

Rollup of 9 pull requests Successful merges: - rust-lang#91795 (resolve/metadata: Stop encoding macros as reexports) - rust-lang#93714 (better ObligationCause for normalization errors in `can_type_implement_copy`) - rust-lang#94175 (Improve `--check-cfg` implementation) - rust-lang#94212 (Stop manually SIMDing in `swap_nonoverlapping`) - rust-lang#94242 (properly handle fat pointers to uninhabitable types) - rust-lang#94308 (Normalize main return type during mono item collection & codegen) - rust-lang#94315 (update auto trait lint for `PhantomData`) - rust-lang#94316 (Improve string literal unescaping) - rust-lang#94327 (Avoid emitting full macro body into JSON errors) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup

resolve: Turn the binding from `#[macro_export]` into a proper `Import` Continuation of rust-lang#91795. ```rust #[macro_export] macro_rules! m { /*...*/ } ``` is desugared to something like ```rust macro_rules! m { /*...*/ } // Non-modularized macro_rules item pub use m; // It's modularized reexport ``` This PR adjusts the internal representation to better match this model.

rust-highfive assigned cjgillot Dec 11, 2021

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 11, 2021

petrochenkov mentioned this pull request Dec 11, 2021

Do not re-export macros that are already at the crate root #88335

Closed