beta regression matching unit-like structs with ..

[durka]

This code

struct Empty;

match Empty {
    Empty(..) => {}
}

compiles on stable 1.5 (no RFC 218 warning) but fails on beta 1.6 with E0164.

[petrochenkov]

This is an expected result of #29383

[durka]

@petrochenkov breaking change with no warning cycle? I expected a warning like there is with a unitary enum variant.

[petrochenkov]

The warning was introduced only for the case UnitVariant(..), other cases were not encountered during crater run.

[durka]

I guess my crate wasn't up during the crater run then :( But this is the point of beta, right, to catch stuff like this?

[petrochenkov]

I don't know, it's possible to turn all errors produced by #29383 into warnings temporarily, but IMHO it's simpler to fix the bug on your side.
This is a policy question, so let's someone else decide.
cc @nikomatsakis as a reviewer of #29383

EDIT: Oh wait, @pnkfelix was the reviewer, but I remember nikomatsakis commented there about errors/warnings.

[alexcrichton]

triage: I-nominated

[durka]

In this case it's in a complex macro (my guard crate) so there really is no workaround until #![feature(braced_empty_structs)]. But you may overrule me by saying tt-based macros are never stable :)

[petrochenkov]

@durka

In this case it's in a complex macro (my guard crate)

https://github.com/durka/guard/blob/master/src/lib.rs#L71
Hmm, does something like self::Empty work as a workaround for this path/identifier problem?

[durka]

Yes (though it's ugly), unless the struct/enum is local to the function/block. So it's a rather niche case I suppose.

[durka]

@petrochenkov actually no, that doesn't seem to help for structs imported from other modules: http://is.gd/TlO9Ro

[petrochenkov]

@durka
Then the module name can be used instead of self - foo::Empty.
I know this is all horrible, but Empty(..) itself is a workaround too.

[pnkfelix]

Hmm, I must have misunderstood #29383 ; I had thought there was a warning cycle associated with this change... e.g. wasn't this comment evidence of such a warning? What did I miss here...

[durka]

@pnkfelix in beta, enums warn while structs error.

[pnkfelix]

@pnkfelix in beta, enums warn while structs error.

Ah! Okay, I see.

[pnkfelix]

@petrochenkov

it's possible to turn all errors produced by #29383 into warnings temporarily, but IMHO it's simpler to fix the bug on your side. This is a policy question, so let's someone else decide.

(I think the appropriate action here is to make them all warnings. But hopefully we'll settle this at the compiler team meeting in a few days.)

[petrochenkov]

@durka
By the way, inability to use identifier in that position is not a parsing/expansion problem, it's a name resolution quirk. Patterns in match and let behave differently - let unlike match never considers identifiers to be variants or consts with rationale "it's rarely what you want".

struct S;

fn main() {
    let S = S; // error: declaration of `S` shadows an enum variant or unit-like struct in scope
}

[durka]

Oh interesting, I didn't realize that was a hard error in some places.

On Mon, Dec 14, 2015 at 6:52 PM, Vadim Petrochenkov <
[email protected]> wrote:

@durka https://github.com/durka
By the way, inability to use identifier in that position is not a
parsing/expansion problem, it's a name resolution quirk. Patterns in match
and let behave differently - let unlike match never considers identifiers
to be variants or consts with rationale "it's rarely what you want"
https://github.com/rust-lang/rust/blob/master/src/librustc_resolve/lib.rs#L2519

struct S;

fn main() {
let S = S; // error: declaration of S shadows an enum variant or unit-like struct in scope
}

—
Reply to this email directly or view it on GitHub
#30379 (comment).

[petrochenkov]

I still think reverting the error doesn't worth the effort.
The broken code in https://github.com/durka/guard is a test code, testing some pretty contrived construction equivalent to if let S(..) = S { /*do nothing*/ } else { return } or if false { return }.

[nikomatsakis]

On Mon, Dec 14, 2015 at 03:52:40PM -0800, Vadim Petrochenkov wrote:

By the way, inability to use identifier in that position is not a parsing/expansion problem, it's a name resolution quirk. Patterns in match and let behave differently - let unlike match never considers identifiers to be variants or consts with rationale "it's rarely what you want"

Huh, yet an other quirk of resolve. I can't say I agree with that
logic. Well, it IS rarely what you want, but I'd probably still treat
them the same! Sigh.

[pnkfelix]

it's possible to turn all errors produced by #29383 into warnings temporarily, but [...]

Compiler team discussed this and decided that we'd prefer to take this tack.

I'll take care of this (after all, I overlooked it in my review of the original PR).

[brson]

@pnkfelix Two weeks until this is released. Needs a fix soon.

[pnkfelix]

@brson thanks, lost this in shuffle of other work

[pnkfelix]

triage: P-high

[pnkfelix]

This is a beta issue; it was an accident for me to close it in PR #30753 itself, since that solely affected nightly.

[brson]

Merged on beta.