Allow qualified paths in struct construction (both expressions and patterns)

[rylev]

Fixes #79658

[rust-highfive]

r? @oli-obk

(rust-highfive has picked a reviewer for you, use r? to override)

[oli-obk]

This lgtm. At this point we should probably do a cleanup (as a follow-up) by introducing some sort of ast::QPath that holds the two fields instead of working with the tuple everywhere. But that will require updates to add appropriate visitor methods and other convenience things.

[oli-obk]

I have reopened #61933 which was originally fixed but is reintroduced with this PR.

Even if this is technically just a bug fix, since this is an insta-stable user-visible language change, I do believe the language team needs to sign off on it.

This PR allows the use of qualified paths in struct patterns and expressions, just like we already allow it for tuple struct patterns and expressions. As an example:

let <Bar as A>::Assoc { br: _br } = <Bar as A>::Assoc { br: 2 };

is allowed after this PR, when it wasn't allowed before.

[rylev]

@nikomatsakis I believe you were going to comment on next steps for this?

[Mark-Simulacrum]

I think it was me :)

We discussed this in the last few lang team meetings, and there was general agreement that this seems like the right path. However, this PR is rather loose on exact description of the change made, and it would be good to write that up (perhaps as the PR description). Specifically, a description of what was allowed before, and what is allowed now; if there's some reason to believe this case was intentionally excluded it would be good to reference the PR that did so and it's rationale as well. We were also interested in knowing if there was a specific driver for this change being made (beyond fixing the mentioned issue).

[rylev]

@Mark-Simulacrum thanks!

The question at hand is should qualified paths type aliases be useable in patterns and expressions for both struct-structs and tuple-structs. This question can be further broken down to: should they be parseable but not pass analysis, not even parseable, or fully useable?

For example, should this code which does not compile in master be made to compile (or at the very least parse)?

fn main() {
    let <WithStructStruct as Trait>::AssociatedType { a } = <WithStructStruct as Trait>::AssociatedType { a: 0 };
    let <WithTupleStruct as Trait>::AssociatedType(a) = <WithTupleStruct as Trait>::AssociatedType(0);
                                                     // ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is the only thing that currently parses 
    let s = StructStruct { a : 0 };
    match s {
       <WithStructStruct as Trait>::AssociatedType { a } => a,
    };

    let s = TupleStruct(0);
    match s {
       <WithTupleStruct as Trait>::AssociatedType(a) => a,
    };
}

struct StructStruct {
    a: usize
}

struct TupleStruct(usize);

trait Trait {
    type AssociatedType;
}

struct WithStructStruct;

impl Trait for WithStructStruct {
    type AssociatedType = StructStruct;
}

struct WithTupleStruct;

impl Trait for WithTupleStruct {
    type AssociatedType = TupleStruct;
}

playground link

Currently in master only tuple structs in expression position parse - though they are not allowed past analysis (rustc_resolve prevents them from being used). Everything else fails to even parse:

let  _ = <WithTupleStruct as Trait>::AssociatedType(0);
// ^ parses but does not compile

It is important to note that the use of struct-structs (but not tuple-structs) with qualified paths is allowed if that struct-struct is referred to behind an alias. For example, the following compiles already:

type Alias = <WithStructStruct as Trait>::AssociatedType;
let alias = Alias { a: 0 } ;
match alias {
  Alias { a } => a,
};

This PR allows the full use of qualified paths in struct-struct patterns and expressions and the parsing of tuple-structs in patterns. Tuple-structs are still not allowed past analysis in both expression and pattern position but this seems wrong (and was an oversight) and should be made consistent with whatever direction we decide to go with struct-structs.

Reasoning

The reason I decided to work on this was due to the need for this in generated code where the generated code knew the trait in question but not the specific associated type. Because of the nature of the associated type it was possible to construct that type but not to name it. To work around this, the alias trick above was used.

This seems like a strange inconsistency that should be resolved. Although it's not often useful, being able to refer to types through qualified paths can be useful in limited circumstances and it does seem natural and unsurprising.

[Mark-Simulacrum]

Tuple-structs are still not allowed past analysis in both expression and pattern position but this seems wrong (and was an oversight) and should be made consistent with whatever direction we decide to go with struct-structs.

To clarify, is this change made in this PR? I think what you have written presents good rationale but it would be helpful to have a more bullet point summary, e.g., something like this, though the following is my hypothesis and not from reading this PR or anything:

Before this PR:

• tuple-structs were parsed, but not resolved, with full UFCS (<Ty as Trait>::AssocType)
• struct-structs were not parsed with full UFCS (<Ty as Trait>::AssocType)
• struct and tuple structs were parsed and resolved with other path forms (as documented in https://doc.rust-lang.org/stable/reference/paths.html)

After this PR:

• struct and tuple structs are parsed and resolved in all path forms (as documented in https://doc.rust-lang.org/stable/reference/paths.html), which simplifies rules and makes things uniform

It would also be good to figure out why this restriction was added/exists - is this just by accident? Maybe @petrochenkov can provide some insight here.

[rylev]

Sorry for the confusion! Let me give it another try:

Before PR

• Usage of a qualified path alias for structs did not parse in the following cases:
  • struct-struct in expression position
  • struct-struct in pattern position
  • tuple-struct in pattern position
• Usage of a qualified path alias for structs parsed but was forbidden in analysis in the following cases:
  • tuple-struct in expression position
• This means that usage of a qualified path alias for structs was not fully allowed in the language in any case.

After this PR

• Usage of a qualified path alias for structs parses in all cases
• Usage of qualified path alias is forbidden in analysis in the following cases:
  • tuple-struct in expression position
  • tuple-struct in pattern position
• Usage of qualified path alias is fully allowed in the following cases:
• struct-struct in expression position
• struct-struct in pattern position

Work that remains to be done

As the PR currently stands there is still an inconsistency as struct-struct and tuple-structs are treated differently. This needs to be changed. I am holding off on fixing this inconsistency until we decide on how to fix the inconsistency.

I believe all these usages should at least parse so at the very least we can provide better error messages. What needs to be decided is if we should allow the user to actually use the qualified path syntax in the expression and/or pattern position.

Therefore, this PR needs to be updated to either:

• disallow struct-struct usage in both expression and pattern position just like the PR already does not allow for tuple-structs. This does not change language semantics and will just ensure better diagnostics.
• allow tuple-struct usage in both pattern and expression position just like the PR already does allow for struct-structs. This changes language semantics.

It was my understanding that this restriction is purely a historical accident as usage of this syntax is likely not very common as @petrochenkov points out here.

[JohnCSimon]

merge conflicts

@JohnCSimon label: +S-waiting-on-author -S-waiting-on-author

[oli-obk]

@bors delegate+

please rebase and then use @bors r=oli-obk to send the PR off again

[bors]

✌️ @rylev can now approve this pull request

[petrochenkov]

r=me with commits squashed.

[petrochenkov]

@bors r+

[bors]

📌 Commit 6936349 has been approved by petrochenkov

[bors]

⌛ Testing commit 6936349 with merge 16e1839...

[bors]

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing 16e1839 to master...

[programmerjake]

Where's the tracking issue for this? it just points to this pull request...

[rylev]

@programmerjake there was no tracking issue for this. I will make one, and change where the feature gate points to.