resolve/metadata: Stop encoding macros as reexports by petrochenkov · Pull Request #91795 · rust-lang/rust

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-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.

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/rust#91795.

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