Prevent None and All members in flags enums

[RX14]

This is my first "real" compiler contribution, please tell me if there's anything I could improve.

See #1251.

[RX14]

Just saw these specs. As per #1251 I don't see a usage for redefining those so i'll remove the specs.

[bcardiff]

Happy compiler hacking then!

I think we need to allow redefining All and None for enums inside libs. We can't assume the None/All semantic will hold outside crystal.

In the current state the user is able to override All and None members. It could lead to some inconsistencies where Member & All != Member or Member | None == Member, etc. So, we are missing that. But probably users will define none and all not knowing that they are autogenerated.

So.

1. I would add in the compiler error a ", they are autogenerated."
2. I would allow redefinition if the enum is inside a lib.

[RX14]

These two fixup commits should fix your feedback.

[Sija]

Shouldn't that be {"none", "all"}.includes?(member.name.downcase)?

[RX14]

enum Foo
  Foo
  FOo
  FOO
end

Foo.values # => [Foo, FOo, FOO]

https://carc.in/#/r/208b

[RX14]

This PR seems to be fixed on macos now.

[mverzilli]

@RX14, I think I rushed a bit to merge this, and I should have requested you to review the related documentation to make sure it at least is consistent with these changes. Would mind doing that and sending another PR along?

[RX14]

@mverzilli Not a problem, is it just the language reference that needs updating? I can't think of anywhere else where this would be documented.

[mverzilli]

Actually nevermind. It is a subtle detail and in general we try to keep the language reference simple and straight to the point. Thanks!

[RX14]

@mverzilli I've looked through the language reference section and I agree with you, it's the wrong place for this detail.

[oprypin]

Hi, I just noticed this and realized that my project has been "broken" by this. It's no big deal, I can just remove my definition of None, but I am losing a documented enum member with important information.
https://github.com/oprypin/crsfml/blob/v2.4.4/src/window/obj.cr#L1940
Talking in IRC, I think we agree that due to this usecase it should be possible to redefine None and All but only if their value matches what they would have been anyway.