fix: resolve E0119 trait coherence error in rustc >= 1.95.0

[itsarraj]

Replaced the use of the associated type < as ModifierValue>::Type with the concrete type via target_ty!( ?) in the generated From trait implementations inside format_item.rs.

This prevents trait coherence conflicts (E0119) in newer versions of the Rust compiler (1.95.0+), which are stricter about blanket implementations and associated types overlapping with downstream generic implementations (such as in cookie or actix-web).

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.4%. Comparing base (5d8737c) to head (182eeb4).

Additional details and impacted files

@@          Coverage Diff          @@
##            main    #786   +/-   ##
=====================================
  Coverage   88.4%   88.4%           
=====================================
  Files         99      99           
  Lines      13079   13079           
=====================================
+ Hits       11556   11557    +1     
+ Misses      1523    1522    -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jhpratt]

Stop pinging people. It is obnoxious and will get you blocked.

[agene0001]

any eta on when this will be merged. getting the same issue in my codebase

[jhpratt]

The version in question has been yanked from crates.io. As such, there is no urgency. If I get more Cargo.tomls that were affected as mentioned in #783, that would speed up my analysis.

[jplatte]

I think this fix is likely correct, as these impls are almost certainly triggering a rustc bug I've encountered before: rust-lang/rust#85898

[jhpratt]

Christ that's an old bug. Must not be terribly easy to fix if it's been around for over a decade.

Given that this already has a known compiler bug, I've got to agree that this is the fix. I'll get back around to it later before releasing.

[jplatte]

This seems like the sort of thing that will be fixed, or at least the fix unblocked, by the new trait solver. Which is actually getting very close to passing a full crater run, AFAIK.

[demurgos]

I've posted a minimal repro in the issue thread: #783 (comment).

Based on testing, I confirm that the issue is related to the usage of the associated type in impl From<HourBase> for <HourBase as ModifierValue>::Type {...}. The trait solver does not evaluate <HourBase as ModifierValue>::Type as bool which then causes the observed issue.

Since both <HourBase as ModifierValue>::Type and bool should be equivalent, this is definitely a Rustc bug (as linked above), and "evaluating" it manually by simply writing in the concrete type bool will fix this problem while keeping the same semantics. In general, the macro should expand to use public type for the modifier.

The macro is already defining the associated type using target_ty!:

        $(#[expect($expect_inner)])?
        impl ModifierValue for $name {
            type Type = target_ty!($name $($target_ty)?);
        }

So reusing it to define the impl target is the right thing to do, the fix in the PR is correct.