Stream: t-compiler

Topic: rfc-2008


davidtwco (Jul 22 2018 at 12:41, on Zulip):

So I'm happy to take on any of the extra work remaining for #44109.

nikomatsakis (Jul 22 2018 at 12:44, on Zulip):

looks like that is mostly enum variant implementation?

davidtwco (Jul 22 2018 at 12:44, on Zulip):

That's all I think.

nikomatsakis (Jul 22 2018 at 12:44, on Zulip):

that is pretty out of cache for me but doesn't seem super hard

davidtwco (Jul 23 2018 at 20:03, on Zulip):

Do you think you'd be able to throw together some high level pointers? Only if you've got the time of course.

nikomatsakis (Jul 24 2018 at 04:01, on Zulip):

yep adding to my list for today

davidtwco (Jul 26 2018 at 14:41, on Zulip):

@nikomatsakis Think you'd be able to put something together here before next week? I know you're not going to be around next week much so it'd be nice to have something to start with. If you don't have time though, don't worry about it.

nikomatsakis (Jul 26 2018 at 14:51, on Zulip):

whoops forgot -- I had some illegal thing on my to do list, maybe this was it :)

nikomatsakis (Jul 26 2018 at 15:02, on Zulip):

@David Wood do these notes make sense to you?

davidtwco (Jul 26 2018 at 15:10, on Zulip):

Yeah, that's great.

davidtwco (Jul 27 2018 at 12:24, on Zulip):

Submitted #52775 for it.

davidtwco (Jul 30 2018 at 11:40, on Zulip):

A small update here on my progress on this after #52775 (given that I'm interested in seeing the whole RFC implemented) - I'm probably going to attempt to do the prereqs for an actual RFC 2008 variants implementation this week - I have no idea how to do that, so I'll just mess around and see if I can come up with something.

nikomatsakis (Jul 31 2018 at 05:01, on Zulip):

@David Wood are you interested in doing that refactoring that @Vadim Petrochenkov mentioned? (to separate the def-ids for variants and structs?)

davidtwco (Jul 31 2018 at 07:15, on Zulip):

Yeah, definitely @nikomatsakis.

nikomatsakis (Aug 06 2018 at 12:31, on Zulip):

@davidtwco did you ever take a stab at that? want some tips for how to do it?

davidtwco (Aug 06 2018 at 12:35, on Zulip):

@nikomatsakis I ended up not having time, just got back from a short holiday. I'm still happy to do it, would appreciate any tips.

nikomatsakis (Aug 06 2018 at 13:25, on Zulip):

ok hmm I could try to take a look -- this is one of those cases where I guess you make the split and then try to get everything building again, as much as anything =)

nikomatsakis (Aug 06 2018 at 13:25, on Zulip):

but It hink what I would do is to look at the "struct ctor" cases

nikomatsakis (Aug 06 2018 at 13:25, on Zulip):

it will probalby cleanup the code a bunch, or could potentially do so

nikomatsakis (Aug 06 2018 at 13:26, on Zulip):

since my guess would be there are a number of cases there are special-casing "enums vs tuple structs" now that could hopefully be unified

davidtwco (Aug 10 2018 at 13:25, on Zulip):

So, I've not messed around with this that much, but I'm getting nowhere. I can find a bunch of places where struct ctors are registered and all sorts of things like that, but I can't quite work out where it is actually given its id.

nikomatsakis (Aug 10 2018 at 13:33, on Zulip):

the goal here was to separate out the ID of the variant from its constructor?

nikomatsakis (Aug 10 2018 at 13:33, on Zulip):

/me tries to remember

davidtwco (Aug 10 2018 at 13:33, on Zulip):

Yes.

davidtwco (Aug 23 2018 at 19:00, on Zulip):

@nikomatsakis I've mostly been looking at this recently and I'm still making very little progress. I understand where the ids are being assigned for structs/variants and what ids are being assigned and used. I've then managed to introduce another id for variants that I intend to identify the ctor separately from the variant. But as soon as I get that compiling I end up with assertions failing here or there that I struggle to track down the root cause of.

eddyb (Aug 23 2018 at 20:52, on Zulip):

hmm why would you need separate ctor vs variant?

nikomatsakis (Aug 23 2018 at 20:58, on Zulip):

@Vadim Petrochenkov was suggesting this because they want to assign a distinct privacy

nikomatsakis (Aug 23 2018 at 20:59, on Zulip):

@davidtwco sorry, I've been playing constant catch up here :(

eddyb (Aug 23 2018 at 20:59, on Zulip):

oh, #[non_exhaustive] relies on privacy?

eddyb (Aug 23 2018 at 20:59, on Zulip):

just like adding an extra private field?

eddyb (Aug 23 2018 at 20:59, on Zulip):

(except enums don't have private fields)

eddyb (Aug 23 2018 at 20:59, on Zulip):

it seems hard to separate constructors from the variants pattern-matching works

eddyb (Aug 23 2018 at 21:00, on Zulip):

like idk if I could get it right the first few times, I don't know where I would start ripping out the floorboards from

eddyb (Aug 23 2018 at 21:00, on Zulip):

and I would be very suspicious if anything actually worked too well

eddyb (Aug 23 2018 at 21:02, on Zulip):

Also, it seems risky because it wouldn't be imported in one of the namespaces, potentially

eddyb (Aug 23 2018 at 21:03, on Zulip):

I would prefer it if they weren't split but privacy wasn't used

eddyb (Aug 23 2018 at 21:03, on Zulip):

or it was checked differently? is it really not possible to do without splitting variants from their constructors?

nikomatsakis (Aug 23 2018 at 21:06, on Zulip):

oh, #[non_exhaustive] relies on privacy?

well, in the case of a tuple struct/variant, it makes the ctor "crate private" I think?

nikomatsakis (Aug 23 2018 at 21:07, on Zulip):

or it was checked differently? is it really not possible to do without splitting variants from their constructors?

I think it is possible

nikomatsakis (Aug 23 2018 at 21:07, on Zulip):

I'm not sure what corner cases must be considered, though.

nikomatsakis (Aug 23 2018 at 21:07, on Zulip):

see also @**Vadim Petrochenkov**'s comment, here

eddyb (Aug 23 2018 at 21:07, on Zulip):

so, like, when type-checking the path to access it in an expression

eddyb (Aug 23 2018 at 21:08, on Zulip):

we could "just" check that we're in the same crate, if it's marked with the attribute, right?

eddyb (Aug 23 2018 at 21:08, on Zulip):

I mean, it would be a valid stop-gap?

nikomatsakis (Aug 23 2018 at 21:08, on Zulip):

presumably yes we could sort of special case this

eddyb (Aug 23 2018 at 21:08, on Zulip):

or name resolution could too, I guess

eddyb (Aug 23 2018 at 21:09, on Zulip):

wait, so are the semantics that you have to use Enum::Variant(..) in a pattern, i.e. can't rely on any fields being there?

nikomatsakis (Aug 23 2018 at 21:10, on Zulip):

no, just that you must include .. basically

nikomatsakis (Aug 23 2018 at 21:10, on Zulip):

i.e., new fields may be added

nikomatsakis (Aug 23 2018 at 21:10, on Zulip):

I believe that is the semantics, anyway

eddyb (Aug 23 2018 at 21:10, on Zulip):

at the end?

nikomatsakis (Aug 23 2018 at 21:10, on Zulip):

right

nikomatsakis (Aug 23 2018 at 21:11, on Zulip):

one could also imagine changing privacy so that -- for any given def-id -- we have multiple privacy values

nikomatsakis (Aug 23 2018 at 21:11, on Zulip):

e.g., separate type/value privacy

nikomatsakis (Aug 23 2018 at 21:11, on Zulip):

I'm not really sure how that stuff all works anymore

nikomatsakis (Aug 23 2018 at 21:11, on Zulip):

the PR that @davidtwco wrote already handled the pattern stuff — or at least some of it

nikomatsakis (Aug 23 2018 at 21:11, on Zulip):

but not the expression position

eddyb (Aug 23 2018 at 21:11, on Zulip):

why do we want to use privacy? it's not like the attribute disappears?

nikomatsakis (Aug 23 2018 at 21:12, on Zulip):

I think @Vadim Petrochenkov just thought it was an elegant way to achieve the end

eddyb (Aug 23 2018 at 21:12, on Zulip):

I'm a bit confused because the interactions seem subtle

eddyb (Aug 23 2018 at 21:12, on Zulip):

if the constructor doesn't get imported... can I shadow it?

nikomatsakis (Aug 23 2018 at 21:12, on Zulip):

presumably yes

eddyb (Aug 23 2018 at 21:12, on Zulip):

does pattern-matching a tuple variant work without it being in the value namespace?

eddyb (Aug 23 2018 at 21:12, on Zulip):

this seems very scary to me

nikomatsakis (Aug 23 2018 at 21:12, on Zulip):

/me wishes we didn't even have tuple structs most of the time

nikomatsakis (Aug 23 2018 at 21:13, on Zulip):

hmm yes that is a good question

eddyb (Aug 23 2018 at 21:13, on Zulip):

I want to keep namespaces filled, just in case

eddyb (Aug 23 2018 at 21:13, on Zulip):

so I don't think privacy is the answer tbqh

nikomatsakis (Aug 23 2018 at 21:13, on Zulip):

interesting. it always seemed a bit surprising to me

eddyb (Aug 23 2018 at 21:13, on Zulip):

tuple structs seem even more predisposed to shenanigans

nikomatsakis (Aug 23 2018 at 21:13, on Zulip):

but I hadn't thought about it very hard

nikomatsakis (Aug 23 2018 at 21:13, on Zulip):

it just seemed like a bit of a "clever hack"

eddyb (Aug 23 2018 at 21:14, on Zulip):

I would prefer it for non-braced pattern-matching to have the entry in the value namespace

nikomatsakis (Aug 23 2018 at 21:14, on Zulip):

vs directly expressing the idea

eddyb (Aug 23 2018 at 21:14, on Zulip):

otherwise we might get some weird results in the future

eddyb (Aug 23 2018 at 21:14, on Zulip):

and tbqh I expect you to be matching the constructor, not the type

eddyb (Aug 23 2018 at 21:14, on Zulip):

unless you use braces and numbers in which case... welll

nikomatsakis (Aug 23 2018 at 21:14, on Zulip):

(that said, it's weird that struct ctors have a distinct def-id, but not enum variants)

nikomatsakis (Aug 23 2018 at 21:15, on Zulip):

what's up with that

eddyb (Aug 23 2018 at 21:15, on Zulip):

/me still wants fn foo { a: T, b: U } -> V { ... } foo { a, b }

davidtwco (Aug 23 2018 at 21:15, on Zulip):

As I remember it, when matching against a struct (not unit), enum or variant (not unit), we require that .. (or _ in a match) be included as new fields can be added (where previously if you specified all fields then the compiler wouldn't require a wildcard - now you always require one). And then we lower the visibility of the constructors for those since you can't add new fields if those constructors are being used, since suddenly that fails to compile as not all fields are set.

eddyb (Aug 23 2018 at 21:15, on Zulip):

@nikomatsakis struct ctors never worked without separate identity IIRC

nikomatsakis (Aug 23 2018 at 21:15, on Zulip):

yes, I know, I just can't remember why

eddyb (Aug 23 2018 at 21:15, on Zulip):

it was a hack from the very beginning, and I think it's because they're types

eddyb (Aug 23 2018 at 21:15, on Zulip):

variants aren't types

eddyb (Aug 23 2018 at 21:16, on Zulip):

so you couldn't have typeof Foo be fn(...) -> Foo

eddyb (Aug 23 2018 at 21:16, on Zulip):

and Foo being a type

nikomatsakis (Aug 23 2018 at 21:16, on Zulip):

yeah. that makes sense. feels sort of like the wrong hack.

eddyb (Aug 23 2018 at 21:16, on Zulip):

the same DefId could not lead to both a function type and the tuple struct type itself

nikomatsakis (Aug 23 2018 at 21:16, on Zulip):

like, we should have two type-of queries

eddyb (Aug 23 2018 at 21:16, on Zulip):

nowadays we have fn_sig which could maybe handle this, idk

nikomatsakis (Aug 23 2018 at 21:16, on Zulip):

/me shrugs

nikomatsakis (Aug 23 2018 at 21:16, on Zulip):

it's always weird that for variants you have to like pull out the return type

nikomatsakis (Aug 23 2018 at 21:16, on Zulip):

and handle the leaf case

eddyb (Aug 23 2018 at 21:16, on Zulip):

type_of and type_decl?

davidtwco (Aug 23 2018 at 21:17, on Zulip):

w/r/t the ids, both enums and structs have an id as part of Item that identifies them, and then each of those have a VariantDef with a single id - for structs, that is used as the ctor (since a id isn't needed to identify the variant, there's only ever one), and for variants it is used to both identify the variant and as the ctor. So for variants, a new id needs to be added here to separate the variant and it's ctor. At least, that's what I've figured out from digging around.

eddyb (Aug 23 2018 at 21:17, on Zulip):

btw I want to rename a bunch of things and take back "def" and "decl" and do cool things with them. or maybe just "def" not "decl"

eddyb (Aug 23 2018 at 21:18, on Zulip):

@davidtwco I'm unconvinced privacy is the right way to implement this

eddyb (Aug 23 2018 at 21:18, on Zulip):

it seems to create more hazards than problems it solves

davidtwco (Aug 23 2018 at 21:19, on Zulip):

I'm open to any potential route to implement this, privacy is just the approach that I was advised to take initially and what I've been trying to continue with.

eddyb (Aug 23 2018 at 21:19, on Zulip):

IMO the correct approach is that you can't assign a type to an expression that references a constructor from another crate that has #[non_exhaustive] on it

eddyb (Aug 23 2018 at 21:20, on Zulip):

this should be like a dozen lines of code in rustc_typeck, and handle both tuple structs and tuple variants

eddyb (Aug 23 2018 at 21:20, on Zulip):

and not require rewriting half the compiler

eddyb (Aug 23 2018 at 21:21, on Zulip):

unless the condition is more subtle than that? is macro hygiene relevant here?

davidtwco (Aug 23 2018 at 21:21, on Zulip):

I'm not sure.

eddyb (Aug 23 2018 at 21:21, on Zulip):

(if so you can maybe traverse the hygiene information, if it's not destroyed in the HIR)

eddyb (Aug 23 2018 at 21:21, on Zulip):

worst case you do this check in HIR lowering, because that still has the AST

eddyb (Aug 23 2018 at 21:21, on Zulip):

or maybe even in rustc_resolve itself

eddyb (Aug 23 2018 at 21:21, on Zulip):

but not when importing the constructor, when resolving an expression to it

davidtwco (Aug 23 2018 at 21:24, on Zulip):

w/r/t what I've been trying to do (whether that is still relevant or the approach we'll take, I don't know), I have these notes when I was digging around trying to work out what was happening. And the last attempt I made replaced the NodeId in VariantDef with a enum that had a single NodeId if it was a struct and two if it was an enum - I just assigned the correct one when building the VariantDef (starting in the ast with a NodeId then lowering in the HIR). I added some helper functions to access the ctor_id and variant_id and then removed the id function that was there. That meant that I was made aware via compile errors where the id was used previously so I could dig around in all those locations and try update relevant code. I got that compiling but I ended up with issues in AdtDef::variant_with_id.

eddyb (Aug 23 2018 at 21:25, on Zulip):

https://github.com/rust-lang/rust/blob/master/src/librustc_resolve/lib.rs#L535

eddyb (Aug 23 2018 at 21:25, on Zulip):

basically this case https://github.com/rust-lang/rust/blob/master/src/librustc_resolve/lib.rs#L555-L556

eddyb (Aug 23 2018 at 21:26, on Zulip):

I think all you have to do is pass something to it so it can... oh hmm

eddyb (Aug 23 2018 at 21:27, on Zulip):

you might have to do this in rustc_typeck to properly get access to cross-crate attributes

eddyb (Aug 23 2018 at 21:28, on Zulip):

@davidtwco you can try to add a check here: https://github.com/rust-lang/rust/blob/master/src/librustc_typeck/check/mod.rs#L3821

eddyb (Aug 23 2018 at 21:28, on Zulip):

just above that line

eddyb (Aug 23 2018 at 21:28, on Zulip):

it should work on top of master, without touching any other part of the codebase

eddyb (Aug 23 2018 at 21:29, on Zulip):

IMO that seems vastly preferably to touching privacy

eddyb (Aug 23 2018 at 21:29, on Zulip):

ofc @Vadim Petrochenkov might have some really good reasons and I'm sorry if I should've read something before saying all this

eddyb (Aug 23 2018 at 21:30, on Zulip):

(but without more information, a specific check at one location seems ideal)

Vadim Petrochenkov (Aug 23 2018 at 21:32, on Zulip):

Of course I have really good reasons :)

eddyb (Aug 23 2018 at 21:32, on Zulip):

oh hey!

Vadim Petrochenkov (Aug 23 2018 at 21:32, on Zulip):

That's exactly the point to make the constructor effectively non-existent for other crates.

eddyb (Aug 23 2018 at 21:32, on Zulip):

I'm curious if you prefer being able to shadow the constructors because of separate privacy and how you think patterns should work

eddyb (Aug 23 2018 at 21:33, on Zulip):

because IMO Foo(..) working in a pattern without Foo in the value namespace just seems scary

Vadim Petrochenkov (Aug 23 2018 at 21:33, on Zulip):

... like this is done now for tuple structs with private fields.

eddyb (Aug 23 2018 at 21:33, on Zulip):

hmm

eddyb (Aug 23 2018 at 21:33, on Zulip):

but you can't pattern-match on those, right? wait, no, you probably can?

Vadim Petrochenkov (Aug 23 2018 at 21:34, on Zulip):

So nobody on the internet knows you are a ~dog~ tuple struct.

Vadim Petrochenkov (Aug 23 2018 at 21:34, on Zulip):

No, you can't match and you can't use them as expressions.

eddyb (Aug 23 2018 at 21:34, on Zulip):

okay that seems... consistent

eddyb (Aug 23 2018 at 21:34, on Zulip):

what about #[non_exhaustive], wouldn't that want to allow pattern-matching?

Vadim Petrochenkov (Aug 23 2018 at 21:34, on Zulip):

Unit structs are the best example here.

eddyb (Aug 23 2018 at 21:34, on Zulip):

if we don't want patterns to work then privacy makes more sense to me

eddyb (Aug 23 2018 at 21:35, on Zulip):

but @nikomatsakis was saying something about adding fields at the end of a tuple struct

Vadim Petrochenkov (Aug 23 2018 at 21:35, on Zulip):

non_exhaustive unit structs are unit only for convenience of the current crate.

eddyb (Aug 23 2018 at 21:35, on Zulip):

okay that's really nice :D

eddyb (Aug 23 2018 at 21:35, on Zulip):

no more pub struct Foo(());

Vadim Petrochenkov (Aug 23 2018 at 21:36, on Zulip):

Other crates cannot use let u = U; using the constructor, because that's kind of... exhaustive.

eddyb (Aug 23 2018 at 21:36, on Zulip):

so far so good (although it would still possible to check this in rustc_typeck or w/e, but I agree privacy works better than I initially expected

eddyb (Aug 23 2018 at 21:37, on Zulip):

so was @nikomatsakis wrong when he said you could pattern-match non-exhaustive tuple-like things with Foo(a, b, ..)? Specifically, that .. at the end being mendatory

eddyb (Aug 23 2018 at 21:37, on Zulip):

should you not be able to write Foo(..) at all?

Vadim Petrochenkov (Aug 23 2018 at 21:37, on Zulip):

eddyb: it was a hack from the very beginning, and I think it's because they're types
eddyb: variants aren't types

eddyb (Aug 23 2018 at 21:37, on Zulip):

maybe only Foo {..}, if that works with unit/tuple/brace the same

Vadim Petrochenkov (Aug 23 2018 at 21:38, on Zulip):

Regarding this ^^, I assumed that variants-as-types will happen sooner or later, so variants will need separate def-ids anyway.

eddyb (Aug 23 2018 at 21:38, on Zulip):

I disagree, but that depends on what we do to structs

eddyb (Aug 23 2018 at 21:39, on Zulip):

I think originally, tuple struct separate constructor ID was a dirty hack, to avoid having a separate type vs value "type of DefId"

eddyb (Aug 23 2018 at 21:40, on Zulip):

I agree that if you already have separate DefId's, it makes some things simpler/lazier

eddyb (Aug 23 2018 at 21:40, on Zulip):

So what are the intended semantics of #[non_exhaustive] on tuple things? not allow pattern-matching at all?

Vadim Petrochenkov (Aug 23 2018 at 21:40, on Zulip):

Yes, for tuple structs/variants Foo(..) doesn't works since nobody knows it's a tuple, but Foo { .. } works.
That's how it's specified in the RFC (full disclosure: under my influence).

eddyb (Aug 23 2018 at 21:40, on Zulip):

oh okay so @nikomatsakis was just confused :P

Vadim Petrochenkov (Aug 23 2018 at 21:41, on Zulip):

So what are the intended semantics of #[non_exhaustive] on tuple things?

Vadim Petrochenkov (Aug 23 2018 at 21:41, on Zulip):

It pretty much doesn't work, yeah.

eddyb (Aug 23 2018 at 21:41, on Zulip):

okay then I agree we don't have much of a choice but treat bracey things as part of the type namespace

eddyb (Aug 23 2018 at 21:41, on Zulip):

which is pretty consistent already

eddyb (Aug 23 2018 at 21:41, on Zulip):

so a DefId split for privacy is fine, just a lot of work

Vadim Petrochenkov (Aug 23 2018 at 21:42, on Zulip):

The only possible thing to work is Foo(..) because partial matches still prevent addition of arbitrary new fields.
But for Foo(..) we have Foo { .. } too, so it's not critical.

davidtwco (Aug 23 2018 at 21:48, on Zulip):

@Vadim Petrochenkov Do you have any tips for how I'd go about making this separation in a managable way? I'm eager to see RFC 2008's implementation through and this is a good opportunity to get some familiarity with parts of the compiler that aren't the MIR.

nikomatsakis (Aug 23 2018 at 21:51, on Zulip):

oh okay so @nikomatsakis was just confused :P

sounds like it, seems fine

nikomatsakis (Aug 23 2018 at 21:51, on Zulip):

known to happen on occasion :)

eddyb (Aug 23 2018 at 21:52, on Zulip):

I'm glad I was scared for no reason, at least

Vadim Petrochenkov (Aug 23 2018 at 21:54, on Zulip):

@Vadim Petrochenkov Do you have any tips for how I'd go about making this separation in a managable way? I'm eager to see RFC 2008's implementation through and this is a good opportunity to get some familiarity with parts of the compiler that aren't the MIR.

No, sorry, can't say more than "separate them and try to make compiler to work again".
I tried to do this about three years ago and couldn't.

eddyb (Aug 23 2018 at 21:55, on Zulip):

if it's edition-relevant I could try to step in

eddyb (Aug 23 2018 at 21:55, on Zulip):

otherwise, probably not

Vadim Petrochenkov (Aug 23 2018 at 21:55, on Zulip):

Now the stuff around def-ids is much cleaner though, so it may be simpler.

davidtwco (Aug 23 2018 at 21:57, on Zulip):

That's... encouraging? I guess I'll just keep at it and see how much it breaks my soul.

nikomatsakis (Aug 23 2018 at 21:57, on Zulip):

heh

davidtwco (Mar 23 2019 at 02:18, on Zulip):

@Vadim Petrochenkov @nikomatsakis I've submitted #59376 with an attempt at RFC 2008 for enum variants. It's probably my biggest PR yet, so I'm sure there are plenty of things I could have done better, happy as always to make any requested changes - there are definitely some parts that could be better. This time it separates the DefId of enum variants and their constructors so should have implemented the RFC properly.

Erich Gubler (Apr 29 2019 at 22:15, on Zulip):

Have there been any updates on this? Is the only thing left updating docs before it can be considered for stabilization?

davidtwco (Apr 29 2019 at 22:24, on Zulip):

I've been intending to finish it off with any documentation that's needed after it had some time to bake in nightly.

davidtwco (Apr 29 2019 at 22:25, on Zulip):

(if you wish to make a PR with documentation or anything like that, please feel free to, but if you don't, I'll eventually get around to it, probably soon-ish now you've reminded me)

nikomatsakis (Apr 30 2019 at 20:05, on Zulip):

Ah, yeah, that'd be a nice thing to finish up.

centril (May 01 2019 at 04:11, on Zulip):

@nikomatsakis I'm not sure about #[non_exhaustive] as concrete syntax; the suggestion .. from the RFC was imo not considered sufficiently and I know some other people in the team like .. also. But it seems like a good discussion item for a meeting.

centril (May 01 2019 at 04:12, on Zulip):

As I noted to @davidtwco, it would be nice to also extend the tests re. #[non_exhaustive] to ensure that e.g. #[non_exhaustive] struct A(!); isn't considered uninhabited outside of the crate.

centril (May 01 2019 at 04:12, on Zulip):

(since I have plans for #[non_exhaustive] + inhabitedness)

nikomatsakis (May 01 2019 at 13:15, on Zulip):

@centril I'd be fine with discussing the syntax some more

davidtwco (May 04 2019 at 00:27, on Zulip):

@centril #60529

centril (May 04 2019 at 00:28, on Zulip):

/me looks

davidtwco (May 04 2019 at 10:52, on Zulip):

@centril to clarify, you want functions like these added:

fn cannot_empty_match_on_empty_struct_to_anything(x: UninhabitedStruct) -> A {
    match x {} //~ ERROR non-exhaustive patterns
}

fn cannot_empty_match_on_empty_tuple_struct_to_anything(x: UninhabitedTupleStruct) -> A {
    match x {} //~ ERROR non-exhaustive patterns
}

fn cannot_empty_match_on_enum_with_empty_variants_struct_to_anything(x: UninhabitedVariants) -> A {
    match x {} //~ ERROR non-exhaustive patterns
}

with these errors:

error[E0004]: non-exhaustive patterns: pattern `UninhabitedStruct` of type `uninhabited::UninhabitedStruct` is not handled
  --> /home/david/projects/rust/rust2/src/test/ui/rfc-2008-non-exhaustive/uninhabited/match.rs:23:11
   |
LL |     match x {} //~ ERROR non-exhaustive patterns
   |           ^
   |
   = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms

error[E0004]: non-exhaustive patterns: pattern `UninhabitedTupleStruct` of type `uninhabited::UninhabitedTupleStruct` is not handled
  --> /home/david/projects/rust/rust2/src/test/ui/rfc-2008-non-exhaustive/uninhabited/match.rs:27:11
   |
LL |     match x {} //~ ERROR non-exhaustive patterns
   |           ^
   |
   = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms

error[E0004]: non-exhaustive patterns: multiple patterns of type `uninhabited::UninhabitedVariants` are not handled
  --> /home/david/projects/rust/rust2/src/test/ui/rfc-2008-non-exhaustive/uninhabited/match.rs:31:11
   |
LL |     match x {} //~ ERROR non-exhaustive patterns
   |           ^
   |
   = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms
davidtwco (May 04 2019 at 10:52, on Zulip):

That will also fail in the _same_crate variant of the test?

centril (May 04 2019 at 10:53, on Zulip):

@davidtwco that looks right, with the caveat that if you enable #![feature(exhaustive_patterns)] then _same_crate should work for the structs.

davidtwco (May 04 2019 at 10:53, on Zulip):

Alright.

centril (May 04 2019 at 10:53, on Zulip):

since that enables the structural behavior for product types

centril (May 04 2019 at 10:55, on Zulip):

(but with #![feature(exhaustive_patterns)] and cross crate then UninhabitedMyProduct should still fail)

davidtwco (May 04 2019 at 10:56, on Zulip):

That matches what I'm seeing.

centril (May 04 2019 at 10:57, on Zulip):

Great :tada:

davidtwco (May 04 2019 at 10:57, on Zulip):

And you also wanted tests with a level of indirection? like in this example from your comment:

#![feature(exhaustive_patterns)]

enum V {}
struct A(V);

fn foo(x: A) -> String {
    match x {}
}
davidtwco (May 04 2019 at 11:08, on Zulip):

Added a bunch of tests to the PR.

centril (May 04 2019 at 11:12, on Zulip):

@davidtwco Let's call it an unintentional want ;)

centril (May 04 2019 at 11:13, on Zulip):

Would be great to have it but it was mainly for explanatory purposes ^^

davidtwco (May 04 2019 at 11:13, on Zulip):

I added them.

centril (May 04 2019 at 11:13, on Zulip):

Awesome

centril (May 04 2019 at 11:31, on Zulip):

@davidtwco indirect_match_same_crate.rs looks strange; shouldn't it be without #![feature(non_exhaustive)] -- also you say "will compile" but it doesn't seem so?

centril (May 04 2019 at 11:32, on Zulip):

if it is without #![feature(non_exhaustive)] then not compiling on some stuff seems expected

centril (May 04 2019 at 11:34, on Zulip):

(being more conservative than my expectation is fine if that is what happens)

centril (May 04 2019 at 11:36, on Zulip):

aah sorry, mixed up feature gates!

davidtwco (May 04 2019 at 12:00, on Zulip):

@centril I think I just mixed up the comment in that test, fixed now.

centril (May 04 2019 at 12:02, on Zulip):

yep

Last update: Nov 20 2019 at 01:15UTC