Shoyu Vanilla (Flint)

> try to unify Equate and Sub to make them closer to nll::TypeRelating It seems to be done by #121462, I guess?

> completely merge Equate/Sub and nll:TypeRelating And `nll::TypeRelating` is moved into `rustc_borrowck` in #121321

If we type `self.i(or any one or more letters)` the macro is fully expanded despite of possible semantic errors that no such field exists, but if we type `self.` only,...

The reason why `dbg!` isn't expanded is in my first [link](https://github.com/rust-lang/rust-analyzer/blob/master/crates/mbe/src/expander/matcher.rs#L497-L526). https://github.com/rust-lang/rust-analyzer/blob/4a8d0f7f565b6df45da5522dd7366a4df3460cd7/crates/mbe/src/expander/matcher.rs#L494-L527 In L497, function `match_meta_var` gets result from the parser, so it makes error for no proper expression following...

```rust pub struct Foo { bar: i32, } macro_rules! our_dbg { ($val:expr $(,)?) => { $val }; ($($val:expr),+ $(,)?) => { ($(our_dbg!($val)),+,) }; } fn baz(foo: Foo) { our_dbg!(foo.bar, foo.$0);...

Well, though I haven't looked into the every detail, but the logic diverges on error for whether or not to push item into `bb_items` And that `bb_items` differece made parsing...

Hello @IvarWithoutBones, would you happen to have time to finish this PR? We're planning to deprecate some of the SyntaxEditor APIs soon, so it would be ideal if this could...

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

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

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