Document local_inner_macros #53464
Comments
SimonSapin
added
A-macros
|
This is
|
|
Perhaps diagnostics could be better though, at least mentioning |
petrochenkov
added
the
A-diagnostics
|
Where is this specified? I couldn’t find Regardless, this is a case of code that compiles on earlier versions and doesn’t anymore. And it’s probably not the only instance. |
petrochenkov
added
the
A-docs
At least in the pull request introducing the feature :) |
|
Oh, I've just noticed, |
dtolnay
removed
A-diagnostics
dtolnay
changed the title
matches crate regression: error[E0433]: failed to resolve. Did you mean std::panic?
|
As @petrochenkov explained, the behavior of Let's track documentation here and file separate issues if there are concrete suggestions for improvements to the diagnostic. |
|
I’ve published https://crates.io/crates/matches/0.1.8 which removes the "tts as expr" macro hack that is unnecessary since Rust 1.12. This in turn makes |
It allows to use the Rust2018-style macro imports correctly:
```rust
use juniper::graphql_object;
graphql_object!(User: () |&self| { ... });
```
In the future when dropping compatibility with pre-2018 compilers,
it is able to be replaced with the explicit `$crate` prefixes instead of
`local_inner_macros`.
In `macro_rules!` with the annotation `local_inner_macros`, all of macro calls
are transformed into `$crate::builtin!(...)` (See [1] for details).
Therefore, name resolutions of built-in macros are not perfomed correctly.
To avoid such situation, some helper macros are introduced to make built-in
macros be interpreted as crate-local macros.
[1]: rust-lang/rust#53464 (comment)
It allows to use the Rust2018-style macro imports correctly:
```rust
use juniper::graphql_object;
graphql_object!(User: () |&self| { ... });
```
In the future when dropping compatibility with pre-2018 compilers,
it is able to be replaced with the explicit `$crate` prefixes instead of
`local_inner_macros`.
In `macro_rules!` with the annotation `local_inner_macros`, all of macro calls
are transformed into `$crate::builtin!(...)` (See [1] for details).
Therefore, name resolutions of built-in macros are not perfomed correctly.
To avoid such situation, some helper macros are introduced to make built-in
macros be interpreted as crate-local macros.
[1]: rust-lang/rust#53464 (comment)
It allows to use the Rust2018-style macro imports correctly:
```rust
use juniper::graphql_object;
graphql_object!(User: () |&self| { ... });
```
In the future when dropping compatibility with pre-2018 compilers,
it is able to be replaced with the explicit `$crate` prefixes instead of
`local_inner_macros`.
In `macro_rules!` with the annotation `local_inner_macros`, all of macro calls
are transformed into `$crate::builtin!(...)` (See [1] for details).
Therefore, name resolutions of built-in macros are not perfomed correctly.
To avoid such situation, some helper macros are introduced to make built-in
macros be interpreted as crate-local macros.
[1]: rust-lang/rust#53464 (comment)
This enables Rust2018-style macro imports:
```rust
use juniper::graphql_object;
graphql_object!(User: () |&self| { ... });
```
In the future when dropping compatibility with pre-2018 compilers,
this can be replaced with the explicit `$crate` prefixes instead of
`local_inner_macros`.
In `macro_rules!` with the annotation `local_inner_macros`, all of macro calls
are transformed into `$crate::builtin!(...)` (See [1] for details).
Therefore, name resolutions of built-in macros are not perfomed correctly.
To avoid this, some helper macros are introduced to make built-in
macros be interpreted as crate-local macros.
[1]: rust-lang/rust#53464 (comment)
pnkfelix
added
the
T-compiler
|
Looks like rust-lang/edition-guide#117 resolves this. |
|
Yep, let's close in favor of that. Thanks! |
Was: `matches` crate regression: error[E0433]: failed to resolve. Did you mean `std::panic`?
Reduced test case:
Commit range: b202882...1fa9449
Likely candidate: #50911 Stabilize
use_extern_macros, CC @petrochenkovThe text was updated successfully, but these errors were encountered: