GCA: `tracing` crate is unusable

[nazar-pc]

Code

I tried this code:

tracing::debug!(
    %id,
    adapter_info = ?adapter_info,
    "Compatible adapter found"
);

https://github.com/nazar-pc/abundance/blob/3d931f62d0a7c85e29a179f67bcb31b1eafeadae/crates/farmer/ab-proof-of-space-gpu/src/host.rs#L123-L127

This is something that works on stable and worked on nightly before. Now I added this to the crate (I used generic_const_exprs before):

#![feature(generic_const_args, generic_const_items, min_generic_const_args)]

I expected to see this happen: Code compiles

Instead, this happened:

error[E0107]: missing generics for struct `tracing::__macro_support::FieldName`
    --> crates/farmer/ab-proof-of-space-gpu/src/host.rs:123:25
     |
 123 | /                         debug!(
 124 | |                             %id,
 125 | |                             adapter_info = ?adapter_info,
 126 | |                             "Compatible adapter found"
 127 | |                         );
     | |_________________________^ expected 1 generic argument
     |
note: struct defined here, with 1 generic parameter: `N`
    --> /home/nazar-pc/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tracing-0.1.44/src/lib.rs:1074:16
     |
1074 |     pub struct FieldName<const N: usize>([u8; N]);
     |                ^^^^^^^^^ --------------
     = note: this error originates in the macro `$crate::__tracing_stringify` which comes from the expansion of the macro `debug` (in Nightly builds, run with -Z macro-backtrace for more info)
help: add missing generic argument
    -->  /home/nazar-pc/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tracing-0.1.44/src/macros.rs:3250:47
     |
3250 |             $crate::__macro_support::FieldName<N>::len($crate::__macro_support::stringify!($($k).+))
     |                                               +++

Version it worked on

Any stable version, nightly at least until nightly-2026-05-03 (without GCA)

Version with regression

rustc --version --verbose:

rustc 1.98.0-nightly (cced03bfd 2026-05-28)
binary: rustc
commit-hash: cced03bfd61a304243a34504618ecec86c17063f
commit-date: 2026-05-28
host: x86_64-unknown-linux-gnu
release: 1.98.0-nightly
LLVM version: 22.1.6

This is the version I'm using right now that has this issue, I didn't use GCA before so not sure when it regressed exactly.

[Dnreikronos]

I dug into this. The root cause is in how a braced const argument is lowered under min_generic_const_args.

FieldName<{ FieldName::len() }> lowers the braced FieldName::len() to ConstArgKind::TupleCall, because AST lowering treats any path(args) call expression in const-arg position as a tuple constructor. Then lower_const_arg_tuple_call lowers the callee's Self type, FieldName, which was written without its const N: usize argument. That bare type is what triggers the "missing generics" (E0107) cascade. But FieldName::len() is an associated-function call, not a constructor, so treating it as a TupleCall is wrong to begin with.

That leaves a design question I'd like to confirm before sending a PR: how should mgca treat a braced, non-constructor call in const-arg position?

(a) Reject it and require const { ... }, reusing the "complex const arguments must be placed inside of a const block" diagnostic that AST lowering already emits for other complex expressions. tracing's macro expansion would then need to wrap the call in const { }.

(b) Accept the bare braces (fall back to an anon const), so it keeps compiling the way it did before the feature was enabled.

I have (a) implemented: detect the non-constructor self type before lowering it, then emit the const-block diagnostic. Happy to open that PR, but if (b) is the intended behavior the fix looks quite different, so I'd rather confirm the direction first.

Could whoever owns the mgca work say which behavior is intended?

[nazar-pc]

I'll not pretend to understand, but it sounds like the root cause might be related to #157178 that I also filed yesterday

[Dnreikronos]

Both come from the same feature being stricter than before, but the mechanisms are different. #157178 is a const item (MAX_U32_AS_U64) used as a generic argument, which mgca now wants declared as type const. This one is a braced call ({ FieldName::len() }) that gets lowered as a tuple constructor when it's actually an associated function. Different code paths, so they'll need separate fixes even though both trace back to mgca rejecting code that built fine before the flag was on. Either way, a maintainer confirming the intended direction here would help.

[Dnreikronos]

@BoxyUwU mind weighing in on the intended mgca behavior here? The question is whether a braced non-constructor call should be rejected (requiring const { }) or accepted as-is. I've got the reject version implemented and can open the PR once you confirm the direction.