False positive `non-primitive cast` error in recent nightly

[frxstrem]

When working for a while in a large codebase, I get a lot of errors like this one from tracing::info! macro invocations:

non-primitive cast: &Arguments<_> as &dyn Value

This seems to come from an expression &(format_args!(...)) as &dyn Value in the macro expansion, which should work (and works according to rustc). std::fmt::Arguments<'_> implements tracing_core::field::Value, however rust-analyzer seems to in some cases still produce an error.

I've so far been unable to create a minimal reproducible example, I've only so far seen this in a fairly large (170k LOC) commercial codebase that I'm working with. Restarting rust-analyzer does make the error go away for a while, in my case for about 1.5 minutes after other errors are visible.

let _ = &format_args!("...") as &dyn std::io::Write; // <-- immediately has error
let _ = &format_args!("...") as &dyn tracing::Value; // <-- has an error after a while

The errors started showing up after updating the rust-analyzer extension earlier today, not sure what the version prior to the update was. The errors seem to not be present on the latest stable release (v0.3.2096). It seems like it may be related to the recently merged #17984.

---

rust-analyzer version: rust-analyzer version: 0.4.2098-standalone

rustc version: rustc 1.80.1 (3f5fd8dd4 2024-08-06)

editor or extension: VSCode, extension version v0.4.2098 (pre-release)

relevant settings: none that I can find

[lnicola]

CC #11847. We might have to mark it as experimental 😞.

[ShoyuVanilla]

I've only so far seen this in a fairly large (170k LOC) commercial codebase that I'm working with.

Is your codebase private?

[ShoyuVanilla]

CC #11847. We might have to mark it as experimental 😞.

This seems to be caused from coerce_unsize as you said. I'll try with the way rustc handles this 🤔

[flodiebold]

This seems to be caused from coerce_unsize as you said. I'll try with the way rustc handles this 🤔

Our CoerceUnsized solving sadly isn't quite correct and probably can't be fixed before the new trait solver is integrated :/

[ShoyuVanilla]

Our CoerceUnsized solving sadly isn't quite correct and probably can't be fixed before the new trait solver is integrated :/

It might be turned out otherwise, but I guess it could be.
The rustc's coerce_unsized solving is ten years old(https://github.com/rust-lang/rust/pull/24619/files#diff-12aa26d34290be9b45ffddf48028dd5af1991fbc8a069414b3ecc250cf48dd0aR295) and I think that this is not so much dependent on sophisticated trait solving infra; it mostly does things by itself I think.
I guess it might work well in r-a here if we adopt that "registering unsolved obligation as InferOk's obligations" strategy.

[flodiebold]

The rustc's coerce_unsized solving is ten years old(https://github.com/rust-lang/rust/pull/24619/files#diff-12aa26d34290be9b45ffddf48028dd5af1991fbc8a069414b3ecc250cf48dd0aR295) and I think that this is not so much dependent on sophisticated trait solving infra; it mostly does things by itself I think. I guess it might work well in r-a here if we adopt that "registering unsolved obligation as InferOk's obligations" strategy.

It uses trait selection (the selcx.select call), which is part of the trait solving infrastructure and something that Chalk doesn't provide access to (but the new trait solver will). Of course it would be possible to replicate that in RA manually, but I'm not sure that's worth it.

[ShoyuVanilla]

The rustc's coerce_unsized solving is ten years old(https://github.com/rust-lang/rust/pull/24619/files#diff-12aa26d34290be9b45ffddf48028dd5af1991fbc8a069414b3ecc250cf48dd0aR295) and I think that this is not so much dependent on sophisticated trait solving infra; it mostly does things by itself I think. I guess it might work well in r-a here if we adopt that "registering unsolved obligation as InferOk's obligations" strategy.

It uses trait selection (the selcx.select call), which is part of the trait solving infrastructure and something that Chalk doesn't provide access to (but the new trait solver will). Of course it would be possible to replicate that in RA manually, but I'm not sure that's worth it.

Rustc branches on selcx.selext result as Ok(None), Err(..)(actually Err branches are two but they are doing error reports anyway) and Ok(Some(..)). Couldn't we do the similar things with db.trait_solve call result as Some(Solution(Ambig)), None and Some(Solution(Unique))?

[flodiebold]

No, select isn't the same as full trait solving.

[ShoyuVanilla]

No, select isn't the same as full trait solving.

Oh, I see 😢

[ShoyuVanilla]

So, we have another reason(one of so many) to quickly migrate into next-gen solver. I hope we could do so in near future.
What would be the proper makeshift fix for this btw? 🤔 Some options I can think up are;

1. Marking cast diagnostics as an experimental feature(so, not triggered by default)
2. Marking the whole cast checks as an experimental feature
3. Ignore cast errors when we are casting into a DST if they are not so obvious

[frxstrem]

I've only so far seen this in a fairly large (170k LOC) commercial codebase that I'm working with.

Is your codebase private?

@ShoyuVanilla yes, it's private so unfortunately I haven't reproduced it with anything I can share here.