Don't show chaining hints for record literals and unit structs

[lnicola]

Fixes #3796

r? @Veetaha

[Veetaha]

Fixes #3796 actually*

[lnicola]

I wonder if there are other expression types we might want to exclude. I think it's fine to leave tuples in.

[Veetaha]

Unit structs maybe and the unit type itself? Basically i think the most general heuristic is "whether the text already contains the type name"

[lnicola]

Good point about those. I'm not sure how to filter them, though, as they show up as a PathExpr and that might exclude too much.

[Veetaha]

Hard to say, looks like we can use the type_of_expr() api Here.
Maybe smth like:

if let Some(ra_hir::Adt::Struct(st)) = sema.type_of_expr(expr).as_adt() {
    if matches!(st.variant_data(), ra_hir_def::VariantData::Unit) {

   }
}

[Veetaha]

Actually, I think the first approach should mostly be using the ra_hir API and not messing with ast when it comes to smth semantics-related.

[matklad]

r? @SomeoneToIgnore :)

[lnicola]

PathExpr also includes constants and other stuff. And variant_data is private.

[SomeoneToIgnore]

Will have a look in an hour.

[lnicola]

I'm still not a fan of the extra allocations.

[SomeoneToIgnore]

You cannot avoid them completely with the current approach to the API, where we avoid excessive reference and lifetimes usage, so I think it's a compromise we have to live with for now.

[Veetaha]

Why not making this a getter like kind -> Union | Record | Tuple. But, here is what I've thought. This will be a false-positive when the expression is not the struct literal, but e.g. some function call that returns a unit or empty-tuple struct. Maybe we lack ra_hir::Expr representation for such cases where we want to determine the kind of expression?

[lnicola]

Good point, added a check for PathExpr.

[SomeoneToIgnore]

LGTM when the "compilation error" in the test is fixed

[SomeoneToIgnore]

Actually, I think the first approach should mostly be using the ra_hir API and not messing with ast when it comes to smth semantics-related.

By the way the PR looks now, it does exaclty this, having the main logic check in hir.
I think this PR a good starting point for now, since requires minimal changes to close the issue and gives the food for thoughts about similar heuristics.

Personally, I'm more concerned about the "do not display chain hint" logic spread over 3 places in the file, but that may be addressed later by some other PR.

[lnicola]

r? @matklad 😄

[matklad]

bors r+

[bors]

Build succeeded

• Rust (windows-latest)
• Rust (ubuntu-latest)
• TypeScript
• Rust (macos-latest)