std: avoid tearing dbg! prints

[joboet]

Fixes#136703.

This is an alternative to #149859. Instead of formatting everything into a string, this PR makes multi-expression dbg! expand into multiple nested matches, with the final match containing a single eprint!. By using macro recursion and relying on hygiene, this allows naming every bound value in that eprint!.

CC @orlp

r? libs

[orlp]

Neat solution :) I wasn't sure if we could use helper macros.

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[joboet]

I'm not sure whether this is really necessary, I just copied this from above.

[samueltardieu]

I don't think this is needed here. You can probably use match arm.body.kind { and add this extra test line to src/tools/clippy/tests/ui/dbg_macro/dbg_macro.rs (and bless the results with ./x test clippy --bless):

takes_async_fn(asyncmove |val| {dbg!(val, val + 1); val });//~^ dbg_macro

[orlp]

Is it allowed to change those error messages to leak those internal details?

[orlp]

An alternative is to stuff the helper macro into the main macro with some kind of marker that would otherwise never be legal, e.g. starting with the tokens => __internal_recursion:

macro_rules! foo {(=> __internal_recursion $x:expr) => {// ...};($x:expr) => {
foo!(=> __internal_recursion $x);};}

[joboet]

Is it allowed to change those error messages to leak those internal details?

I don't think there's currently a way to tell the compiler to hide them unfortunately. But yes, this is fine, or at least there is precedent – the same happens for thread_local!: If you try

thread_local!{
#[rustc_align_static(42)]staticLOCAL:i32 = 42;}

(playground) on stable, the error message will reference $crate::thread::local_impl::thread_local_inner.

An alternative is to stuff the helper macro into the main macro with some kind of marker that would otherwise never be legal, e.g. starting with the tokens => __internal_recursion:

macro_rules! foo {(=> __internal_recursion $x:expr) => {// ...};($x:expr) => {
foo!(=> __internal_recursion $x);};}

It would be legal to write these tokens in macro invocations in user code, so this would be an even worse leak of implementation details. I'm sure there is a way to abuse #[allow_internal_unstable] to make some macro arms unusable from stable, but I don't think its worth the hassle.

[orlp]

It would be legal to write these tokens in macro invocations in user code, so this would be an even worse leak of implementation details.

It would also be legal to directly write std::macros::dbg_internal!, no? So I don't see how it's better/worse in that regard.

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[joboet]

It would be legal to write these tokens in macro invocations in user code, so this would be an even worse leak of implementation details.

It would also be legal to directly write std::macros::dbg_internal!, no? So I don't see how it's better/worse in that regard.

No, since the macro is perma-unstable 😏

[orlp]

How does that work once the macro expands? Does it not expand in the user's context? Or is this just stdlib magic sprinkles?

[joboet]

How does that work once the macro expands? Does it not expand in the user's context? Or is this just stdlib magic sprinkles?

dbg! is marked with #[allow_internal_unstable(std_internals)] which allows dbg_internal! to be used from code generated by the macro (but not in spans passed to the macro) despite it being an unstable feature. We use the same trick for thread_local!, since it too needs to invoke unstable helper macros, which need to use unstable features like #[thread_local] themselves.

Edit: So yes, essentially just stdlib magic sprinkles 😄

[bors]

☔ The latest upstream changes (presumably #150068) made this pull request unmergeable. Please resolve the merge conflicts.

[theemathas]

Should there be release notes for this in 1.96.0?

[joboet]

Fixes#136703.

This is an alternative to #149859. Instead of formatting everything into a string, this PR makes multi-expression dbg! expand into multiple nested matches, with the final match containing a single eprint!. By using macro recursion and relying on hygiene, this allows naming every bound value in that eprint!.

CC @orlp

r? libs

[orlp]

Neat solution :) I wasn't sure if we could use helper macros.

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[joboet]

I'm not sure whether this is really necessary, I just copied this from above.

[samueltardieu]

I don't think this is needed here. You can probably use match arm.body.kind { and add this extra test line to src/tools/clippy/tests/ui/dbg_macro/dbg_macro.rs (and bless the results with ./x test clippy --bless):

takes_async_fn(asyncmove |val| {dbg!(val, val + 1); val });//~^ dbg_macro

[orlp]

Is it allowed to change those error messages to leak those internal details?

[orlp]

An alternative is to stuff the helper macro into the main macro with some kind of marker that would otherwise never be legal, e.g. starting with the tokens => __internal_recursion:

macro_rules! foo {(=> __internal_recursion $x:expr) => {// ...};($x:expr) => {
foo!(=> __internal_recursion $x);};}

[joboet]

Is it allowed to change those error messages to leak those internal details?

I don't think there's currently a way to tell the compiler to hide them unfortunately. But yes, this is fine, or at least there is precedent – the same happens for thread_local!: If you try

thread_local!{
#[rustc_align_static(42)]staticLOCAL:i32 = 42;}

(playground) on stable, the error message will reference $crate::thread::local_impl::thread_local_inner.

An alternative is to stuff the helper macro into the main macro with some kind of marker that would otherwise never be legal, e.g. starting with the tokens => __internal_recursion:

macro_rules! foo {(=> __internal_recursion $x:expr) => {// ...};($x:expr) => {
foo!(=> __internal_recursion $x);};}

It would be legal to write these tokens in macro invocations in user code, so this would be an even worse leak of implementation details. I'm sure there is a way to abuse #[allow_internal_unstable] to make some macro arms unusable from stable, but I don't think its worth the hassle.

[orlp]

It would be legal to write these tokens in macro invocations in user code, so this would be an even worse leak of implementation details.

It would also be legal to directly write std::macros::dbg_internal!, no? So I don't see how it's better/worse in that regard.

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[joboet]

It would be legal to write these tokens in macro invocations in user code, so this would be an even worse leak of implementation details.

It would also be legal to directly write std::macros::dbg_internal!, no? So I don't see how it's better/worse in that regard.

No, since the macro is perma-unstable 😏

[orlp]

How does that work once the macro expands? Does it not expand in the user's context? Or is this just stdlib magic sprinkles?

[joboet]

How does that work once the macro expands? Does it not expand in the user's context? Or is this just stdlib magic sprinkles?

dbg! is marked with #[allow_internal_unstable(std_internals)] which allows dbg_internal! to be used from code generated by the macro (but not in spans passed to the macro) despite it being an unstable feature. We use the same trick for thread_local!, since it too needs to invoke unstable helper macros, which need to use unstable features like #[thread_local] themselves.

Edit: So yes, essentially just stdlib magic sprinkles 😄

[bors]

☔ The latest upstream changes (presumably #150068) made this pull request unmergeable. Please resolve the merge conflicts.

[theemathas]

Should there be release notes for this in 1.96.0?

[joboet]

Fixes#136703.

This is an alternative to #149859. Instead of formatting everything into a string, this PR makes multi-expression dbg! expand into multiple nested matches, with the final match containing a single eprint!. By using macro recursion and relying on hygiene, this allows naming every bound value in that eprint!.

CC @orlp

r? libs

[orlp]

Neat solution :) I wasn't sure if we could use helper macros.

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[joboet]

I'm not sure whether this is really necessary, I just copied this from above.

[samueltardieu]

I don't think this is needed here. You can probably use match arm.body.kind { and add this extra test line to src/tools/clippy/tests/ui/dbg_macro/dbg_macro.rs (and bless the results with ./x test clippy --bless):

takes_async_fn(asyncmove |val| {dbg!(val, val + 1); val });//~^ dbg_macro

[orlp]

Is it allowed to change those error messages to leak those internal details?

[orlp]

An alternative is to stuff the helper macro into the main macro with some kind of marker that would otherwise never be legal, e.g. starting with the tokens => __internal_recursion:

macro_rules! foo {(=> __internal_recursion $x:expr) => {// ...};($x:expr) => {
foo!(=> __internal_recursion $x);};}

[joboet]

Is it allowed to change those error messages to leak those internal details?

I don't think there's currently a way to tell the compiler to hide them unfortunately. But yes, this is fine, or at least there is precedent – the same happens for thread_local!: If you try

thread_local!{
#[rustc_align_static(42)]staticLOCAL:i32 = 42;}

(playground) on stable, the error message will reference $crate::thread::local_impl::thread_local_inner.

An alternative is to stuff the helper macro into the main macro with some kind of marker that would otherwise never be legal, e.g. starting with the tokens => __internal_recursion:

macro_rules! foo {(=> __internal_recursion $x:expr) => {// ...};($x:expr) => {
foo!(=> __internal_recursion $x);};}

It would be legal to write these tokens in macro invocations in user code, so this would be an even worse leak of implementation details. I'm sure there is a way to abuse #[allow_internal_unstable] to make some macro arms unusable from stable, but I don't think its worth the hassle.

[orlp]

It would be legal to write these tokens in macro invocations in user code, so this would be an even worse leak of implementation details.

It would also be legal to directly write std::macros::dbg_internal!, no? So I don't see how it's better/worse in that regard.

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[joboet]

It would be legal to write these tokens in macro invocations in user code, so this would be an even worse leak of implementation details.

It would also be legal to directly write std::macros::dbg_internal!, no? So I don't see how it's better/worse in that regard.

No, since the macro is perma-unstable 😏

[orlp]

How does that work once the macro expands? Does it not expand in the user's context? Or is this just stdlib magic sprinkles?

[joboet]

How does that work once the macro expands? Does it not expand in the user's context? Or is this just stdlib magic sprinkles?

dbg! is marked with #[allow_internal_unstable(std_internals)] which allows dbg_internal! to be used from code generated by the macro (but not in spans passed to the macro) despite it being an unstable feature. We use the same trick for thread_local!, since it too needs to invoke unstable helper macros, which need to use unstable features like #[thread_local] themselves.

Edit: So yes, essentially just stdlib magic sprinkles 😄

[bors]

☔ The latest upstream changes (presumably #150068) made this pull request unmergeable. Please resolve the merge conflicts.

[theemathas]

Should there be release notes for this in 1.96.0?

[joboet]

Fixes#136703.

This is an alternative to #149859. Instead of formatting everything into a string, this PR makes multi-expression dbg! expand into multiple nested matches, with the final match containing a single eprint!. By using macro recursion and relying on hygiene, this allows naming every bound value in that eprint!.

CC @orlp

r? libs

[orlp]

Neat solution :) I wasn't sure if we could use helper macros.

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[joboet]

I'm not sure whether this is really necessary, I just copied this from above.

[samueltardieu]

I don't think this is needed here. You can probably use match arm.body.kind { and add this extra test line to src/tools/clippy/tests/ui/dbg_macro/dbg_macro.rs (and bless the results with ./x test clippy --bless):

takes_async_fn(asyncmove |val| {dbg!(val, val + 1); val });//~^ dbg_macro

[orlp]

Is it allowed to change those error messages to leak those internal details?

[orlp]

An alternative is to stuff the helper macro into the main macro with some kind of marker that would otherwise never be legal, e.g. starting with the tokens => __internal_recursion:

macro_rules! foo {(=> __internal_recursion $x:expr) => {// ...};($x:expr) => {
foo!(=> __internal_recursion $x);};}

[joboet]

Is it allowed to change those error messages to leak those internal details?

I don't think there's currently a way to tell the compiler to hide them unfortunately. But yes, this is fine, or at least there is precedent – the same happens for thread_local!: If you try

thread_local!{
#[rustc_align_static(42)]staticLOCAL:i32 = 42;}

(playground) on stable, the error message will reference $crate::thread::local_impl::thread_local_inner.

An alternative is to stuff the helper macro into the main macro with some kind of marker that would otherwise never be legal, e.g. starting with the tokens => __internal_recursion:

macro_rules! foo {(=> __internal_recursion $x:expr) => {// ...};($x:expr) => {
foo!(=> __internal_recursion $x);};}

It would be legal to write these tokens in macro invocations in user code, so this would be an even worse leak of implementation details. I'm sure there is a way to abuse #[allow_internal_unstable] to make some macro arms unusable from stable, but I don't think its worth the hassle.

[orlp]

It would be legal to write these tokens in macro invocations in user code, so this would be an even worse leak of implementation details.

It would also be legal to directly write std::macros::dbg_internal!, no? So I don't see how it's better/worse in that regard.

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[joboet]

It would be legal to write these tokens in macro invocations in user code, so this would be an even worse leak of implementation details.

It would also be legal to directly write std::macros::dbg_internal!, no? So I don't see how it's better/worse in that regard.

No, since the macro is perma-unstable 😏

[orlp]

How does that work once the macro expands? Does it not expand in the user's context? Or is this just stdlib magic sprinkles?

[joboet]

How does that work once the macro expands? Does it not expand in the user's context? Or is this just stdlib magic sprinkles?

dbg! is marked with #[allow_internal_unstable(std_internals)] which allows dbg_internal! to be used from code generated by the macro (but not in spans passed to the macro) despite it being an unstable feature. We use the same trick for thread_local!, since it too needs to invoke unstable helper macros, which need to use unstable features like #[thread_local] themselves.

Edit: So yes, essentially just stdlib magic sprinkles 😄

[bors]

☔ The latest upstream changes (presumably #150068) made this pull request unmergeable. Please resolve the merge conflicts.

[theemathas]

Should there be release notes for this in 1.96.0?

[joboet]

Fixes#136703.

This is an alternative to #149859. Instead of formatting everything into a string, this PR makes multi-expression dbg! expand into multiple nested matches, with the final match containing a single eprint!. By using macro recursion and relying on hygiene, this allows naming every bound value in that eprint!.

CC @orlp

r? libs

[orlp]

Neat solution :) I wasn't sure if we could use helper macros.

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[joboet]

I'm not sure whether this is really necessary, I just copied this from above.

[samueltardieu]

I don't think this is needed here. You can probably use match arm.body.kind { and add this extra test line to src/tools/clippy/tests/ui/dbg_macro/dbg_macro.rs (and bless the results with ./x test clippy --bless):

takes_async_fn(asyncmove |val| {dbg!(val, val + 1); val });//~^ dbg_macro

[orlp]

Is it allowed to change those error messages to leak those internal details?

[orlp]

An alternative is to stuff the helper macro into the main macro with some kind of marker that would otherwise never be legal, e.g. starting with the tokens => __internal_recursion:

macro_rules! foo {(=> __internal_recursion $x:expr) => {// ...};($x:expr) => {
foo!(=> __internal_recursion $x);};}

[joboet]

Is it allowed to change those error messages to leak those internal details?

I don't think there's currently a way to tell the compiler to hide them unfortunately. But yes, this is fine, or at least there is precedent – the same happens for thread_local!: If you try

thread_local!{
#[rustc_align_static(42)]staticLOCAL:i32 = 42;}

(playground) on stable, the error message will reference $crate::thread::local_impl::thread_local_inner.

An alternative is to stuff the helper macro into the main macro with some kind of marker that would otherwise never be legal, e.g. starting with the tokens => __internal_recursion:

macro_rules! foo {(=> __internal_recursion $x:expr) => {// ...};($x:expr) => {
foo!(=> __internal_recursion $x);};}

It would be legal to write these tokens in macro invocations in user code, so this would be an even worse leak of implementation details. I'm sure there is a way to abuse #[allow_internal_unstable] to make some macro arms unusable from stable, but I don't think its worth the hassle.

[orlp]

It would be legal to write these tokens in macro invocations in user code, so this would be an even worse leak of implementation details.

It would also be legal to directly write std::macros::dbg_internal!, no? So I don't see how it's better/worse in that regard.

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[joboet]

It would be legal to write these tokens in macro invocations in user code, so this would be an even worse leak of implementation details.

It would also be legal to directly write std::macros::dbg_internal!, no? So I don't see how it's better/worse in that regard.

No, since the macro is perma-unstable 😏

[orlp]

How does that work once the macro expands? Does it not expand in the user's context? Or is this just stdlib magic sprinkles?

[joboet]

How does that work once the macro expands? Does it not expand in the user's context? Or is this just stdlib magic sprinkles?

dbg! is marked with #[allow_internal_unstable(std_internals)] which allows dbg_internal! to be used from code generated by the macro (but not in spans passed to the macro) despite it being an unstable feature. We use the same trick for thread_local!, since it too needs to invoke unstable helper macros, which need to use unstable features like #[thread_local] themselves.

Edit: So yes, essentially just stdlib magic sprinkles 😄

[bors]

☔ The latest upstream changes (presumably #150068) made this pull request unmergeable. Please resolve the merge conflicts.

[theemathas]

Should there be release notes for this in 1.96.0?

[joboet]

Fixes#136703.

This is an alternative to #149859. Instead of formatting everything into a string, this PR makes multi-expression dbg! expand into multiple nested matches, with the final match containing a single eprint!. By using macro recursion and relying on hygiene, this allows naming every bound value in that eprint!.

CC @orlp

r? libs

[orlp]

Neat solution :) I wasn't sure if we could use helper macros.

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[joboet]

I'm not sure whether this is really necessary, I just copied this from above.

[samueltardieu]

I don't think this is needed here. You can probably use match arm.body.kind { and add this extra test line to src/tools/clippy/tests/ui/dbg_macro/dbg_macro.rs (and bless the results with ./x test clippy --bless):

takes_async_fn(asyncmove |val| {dbg!(val, val + 1); val });//~^ dbg_macro

[orlp]

Is it allowed to change those error messages to leak those internal details?

[orlp]

An alternative is to stuff the helper macro into the main macro with some kind of marker that would otherwise never be legal, e.g. starting with the tokens => __internal_recursion:

macro_rules! foo {(=> __internal_recursion $x:expr) => {// ...};($x:expr) => {
foo!(=> __internal_recursion $x);};}

[joboet]

Is it allowed to change those error messages to leak those internal details?

I don't think there's currently a way to tell the compiler to hide them unfortunately. But yes, this is fine, or at least there is precedent – the same happens for thread_local!: If you try

thread_local!{
#[rustc_align_static(42)]staticLOCAL:i32 = 42;}

(playground) on stable, the error message will reference $crate::thread::local_impl::thread_local_inner.

An alternative is to stuff the helper macro into the main macro with some kind of marker that would otherwise never be legal, e.g. starting with the tokens => __internal_recursion:

macro_rules! foo {(=> __internal_recursion $x:expr) => {// ...};($x:expr) => {
foo!(=> __internal_recursion $x);};}

It would be legal to write these tokens in macro invocations in user code, so this would be an even worse leak of implementation details. I'm sure there is a way to abuse #[allow_internal_unstable] to make some macro arms unusable from stable, but I don't think its worth the hassle.

[orlp]

It would be legal to write these tokens in macro invocations in user code, so this would be an even worse leak of implementation details.

It would also be legal to directly write std::macros::dbg_internal!, no? So I don't see how it's better/worse in that regard.

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[joboet]

It would be legal to write these tokens in macro invocations in user code, so this would be an even worse leak of implementation details.

It would also be legal to directly write std::macros::dbg_internal!, no? So I don't see how it's better/worse in that regard.

No, since the macro is perma-unstable 😏

[orlp]

How does that work once the macro expands? Does it not expand in the user's context? Or is this just stdlib magic sprinkles?

[joboet]

How does that work once the macro expands? Does it not expand in the user's context? Or is this just stdlib magic sprinkles?

dbg! is marked with #[allow_internal_unstable(std_internals)] which allows dbg_internal! to be used from code generated by the macro (but not in spans passed to the macro) despite it being an unstable feature. We use the same trick for thread_local!, since it too needs to invoke unstable helper macros, which need to use unstable features like #[thread_local] themselves.

Edit: So yes, essentially just stdlib magic sprinkles 😄

[bors]

☔ The latest upstream changes (presumably #150068) made this pull request unmergeable. Please resolve the merge conflicts.

[theemathas]

Should there be release notes for this in 1.96.0?

[joboet]

Fixes#136703.

This is an alternative to #149859. Instead of formatting everything into a string, this PR makes multi-expression dbg! expand into multiple nested matches, with the final match containing a single eprint!. By using macro recursion and relying on hygiene, this allows naming every bound value in that eprint!.

CC @orlp

r? libs

[orlp]

Neat solution :) I wasn't sure if we could use helper macros.

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[joboet]

I'm not sure whether this is really necessary, I just copied this from above.

[samueltardieu]

I don't think this is needed here. You can probably use match arm.body.kind { and add this extra test line to src/tools/clippy/tests/ui/dbg_macro/dbg_macro.rs (and bless the results with ./x test clippy --bless):

takes_async_fn(asyncmove |val| {dbg!(val, val + 1); val });//~^ dbg_macro

[orlp]

Is it allowed to change those error messages to leak those internal details?

[orlp]

An alternative is to stuff the helper macro into the main macro with some kind of marker that would otherwise never be legal, e.g. starting with the tokens => __internal_recursion:

macro_rules! foo {(=> __internal_recursion $x:expr) => {// ...};($x:expr) => {
foo!(=> __internal_recursion $x);};}

[joboet]

Is it allowed to change those error messages to leak those internal details?

I don't think there's currently a way to tell the compiler to hide them unfortunately. But yes, this is fine, or at least there is precedent – the same happens for thread_local!: If you try

thread_local!{
#[rustc_align_static(42)]staticLOCAL:i32 = 42;}

(playground) on stable, the error message will reference $crate::thread::local_impl::thread_local_inner.

An alternative is to stuff the helper macro into the main macro with some kind of marker that would otherwise never be legal, e.g. starting with the tokens => __internal_recursion:

macro_rules! foo {(=> __internal_recursion $x:expr) => {// ...};($x:expr) => {
foo!(=> __internal_recursion $x);};}

It would be legal to write these tokens in macro invocations in user code, so this would be an even worse leak of implementation details. I'm sure there is a way to abuse #[allow_internal_unstable] to make some macro arms unusable from stable, but I don't think its worth the hassle.

[orlp]

It would be legal to write these tokens in macro invocations in user code, so this would be an even worse leak of implementation details.

It would also be legal to directly write std::macros::dbg_internal!, no? So I don't see how it's better/worse in that regard.

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[joboet]

It would be legal to write these tokens in macro invocations in user code, so this would be an even worse leak of implementation details.

It would also be legal to directly write std::macros::dbg_internal!, no? So I don't see how it's better/worse in that regard.

No, since the macro is perma-unstable 😏

[orlp]

How does that work once the macro expands? Does it not expand in the user's context? Or is this just stdlib magic sprinkles?

[joboet]

How does that work once the macro expands? Does it not expand in the user's context? Or is this just stdlib magic sprinkles?

dbg! is marked with #[allow_internal_unstable(std_internals)] which allows dbg_internal! to be used from code generated by the macro (but not in spans passed to the macro) despite it being an unstable feature. We use the same trick for thread_local!, since it too needs to invoke unstable helper macros, which need to use unstable features like #[thread_local] themselves.

Edit: So yes, essentially just stdlib magic sprinkles 😄

[bors]

☔ The latest upstream changes (presumably #150068) made this pull request unmergeable. Please resolve the merge conflicts.

[theemathas]

Should there be release notes for this in 1.96.0?

[joboet]

Fixes#136703.

This is an alternative to #149859. Instead of formatting everything into a string, this PR makes multi-expression dbg! expand into multiple nested matches, with the final match containing a single eprint!. By using macro recursion and relying on hygiene, this allows naming every bound value in that eprint!.

CC @orlp

r? libs

[orlp]

Neat solution :) I wasn't sure if we could use helper macros.

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[joboet]

I'm not sure whether this is really necessary, I just copied this from above.

[samueltardieu]

I don't think this is needed here. You can probably use match arm.body.kind { and add this extra test line to src/tools/clippy/tests/ui/dbg_macro/dbg_macro.rs (and bless the results with ./x test clippy --bless):

takes_async_fn(asyncmove |val| {dbg!(val, val + 1); val });//~^ dbg_macro

[orlp]

Is it allowed to change those error messages to leak those internal details?

[orlp]

An alternative is to stuff the helper macro into the main macro with some kind of marker that would otherwise never be legal, e.g. starting with the tokens => __internal_recursion:

macro_rules! foo {(=> __internal_recursion $x:expr) => {// ...};($x:expr) => {
foo!(=> __internal_recursion $x);};}

[joboet]

Is it allowed to change those error messages to leak those internal details?

I don't think there's currently a way to tell the compiler to hide them unfortunately. But yes, this is fine, or at least there is precedent – the same happens for thread_local!: If you try

thread_local!{
#[rustc_align_static(42)]staticLOCAL:i32 = 42;}

(playground) on stable, the error message will reference $crate::thread::local_impl::thread_local_inner.

An alternative is to stuff the helper macro into the main macro with some kind of marker that would otherwise never be legal, e.g. starting with the tokens => __internal_recursion:

macro_rules! foo {(=> __internal_recursion $x:expr) => {// ...};($x:expr) => {
foo!(=> __internal_recursion $x);};}

It would be legal to write these tokens in macro invocations in user code, so this would be an even worse leak of implementation details. I'm sure there is a way to abuse #[allow_internal_unstable] to make some macro arms unusable from stable, but I don't think its worth the hassle.

[orlp]

It would be legal to write these tokens in macro invocations in user code, so this would be an even worse leak of implementation details.

It would also be legal to directly write std::macros::dbg_internal!, no? So I don't see how it's better/worse in that regard.

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[joboet]

It would be legal to write these tokens in macro invocations in user code, so this would be an even worse leak of implementation details.

It would also be legal to directly write std::macros::dbg_internal!, no? So I don't see how it's better/worse in that regard.

No, since the macro is perma-unstable 😏

[orlp]

How does that work once the macro expands? Does it not expand in the user's context? Or is this just stdlib magic sprinkles?

[joboet]

How does that work once the macro expands? Does it not expand in the user's context? Or is this just stdlib magic sprinkles?

dbg! is marked with #[allow_internal_unstable(std_internals)] which allows dbg_internal! to be used from code generated by the macro (but not in spans passed to the macro) despite it being an unstable feature. We use the same trick for thread_local!, since it too needs to invoke unstable helper macros, which need to use unstable features like #[thread_local] themselves.

Edit: So yes, essentially just stdlib magic sprinkles 😄

[bors]

☔ The latest upstream changes (presumably #150068) made this pull request unmergeable. Please resolve the merge conflicts.

[theemathas]

Should there be release notes for this in 1.96.0?