fix: avoid associated type projection in modifier! From impl

[xlfish233]

The modifier! macro generates From<> using the associated type projection ::Type, which confuses the new trait solver (next-solver=coherence, default since Rust 1.84) during coherence checking. The solver cannot normalize the projection, causing false positive E0119 conflicts with blanket From impls in downstream crates.

Replace the projection with the concrete type via target_ty!, which the macro already uses for ModifierValue::Type. The generated code is identical, but avoids the opaque projection.

[codecov]

Codecov Report

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

Additional details and impacted files

@@          Coverage Diff          @@
##            main    #784   +/-   ##
=====================================
  Coverage   88.4%   88.4%           
=====================================
  Files         99      99           
  Lines      13079   13079           
=====================================
+ Hits       11556   11559    +3     
+ Misses      1523    1520    -3     

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

[xlfish233]

error spot at like: Checking cookie v0.18.1
Checking tracing-subscriber v0.3.23
error[E0119]: conflicting implementations of trait From<format_description::parse::format_item::HourBase> for type <format_description::parse::format_item::HourBase as format_description::parse::format_item::ModifierValue>::Type
--> /home/pgrx/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cookie-0.18.1/src/expiration.rs:129:1
|
129 | impl<T: Into<Option>> From for Expiration {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: conflicting implementation in crate time:
- impl From<format_description::parse::format_item::HourBase> for <format_description::parse::format_item::HourBase as format_description::parse::format_item::ModifierValue>::Type;
= note: upstream crates may add a new impl of trait std::convert::Into<std::option::Option<time::OffsetDateTime>> for type time::format_description::parse::format_item::HourBase in future versions

For more information about this error, try rustc --explain E0119.
error: could not compile cookie (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
error[E0119]: conflicting implementations of trait From<format_description::parse::format_item::HourBase> for type <format_description::parse::format_item::HourBase as format_description::parse::format_item::ModifierValue>::Type
--> /home/pgrx/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tracing-subscriber-0.3.23/src/filter/env/mod.rs:759:1
|
759 | / impl From for EnvFilter
760 | | where
761 | | S: AsRef,
| |__________________^
|
= note: conflicting implementation in crate time:
- impl From<format_description::parse::format_item::HourBase> for <format_description::parse::format_item::HourBase as format_description::parse::format_item::ModifierValue>::Type;
= note: upstream crates may add a new impl of trait core::convert::AsRef<str> for type time::format_description::parse::format_item::HourBase in future versions

error: could not compile tracing-subscriber (lib) due to 1 previous error

[xlfish233]

"This change has no effect on time's behavior, but resolves false-positive E0119 compilation errors in downstream crates like cookie, tracing-subscriber,and salvo_core."

[devalain]

Works for me. Added

[patch.crates-io]
time = { git = "https://github.com/xlfish233/time-fix.git", branch = "fix/coherence-e0119" }

in my Cargo.toml to test your PR.

[mkrasnitski]

Just as a note, I tested with -Znext-solver=no and still run into the same breakage, so the new trait solver may not be at fault.

[xlfish233]

Just as a note, I tested with -Znext-solver=no and still run into the same breakage, so the new trait solver may not be at fault.

Could you give me more context of failure env, for current context i can't figure the root cause of your breakge.

[xlfish233]

Just as a note, I tested with -Znext-solver=no and still run into the same breakage, so the new trait solver may not be at fault.

Thank for the note,i confirmed it actually not the root casue.

And i found diff between 0.3.47 and 0.3.48.

Actually author just changed :

  impl From<$name> for target_ty!($name $($target_ty)?) {

0.3.48 (broken):

  impl From<$name> for <$name as ModifierValue>::Type {

[jhpratt]

I merged #786 as that also changes time-macros, just in case.