Add support for typed and scoped enums

[peterbell10]

Say I have in the c++ side:

enum class EffectID : Int32
{
    SFX_MOB_GHAST_WARN
};

This will be usable in lua as EffectID.SFX_MOB_GHAST_WARN.

[madmaxoft]

Make sure that this doesn't lose any of our current API. Compile Cuberite without these changes, run it and issue the api command (from the APIDump built-in plugin); make a backup of the Server/Cuberite_api.lua file generated by this, and then repeat with these changes. Compare the two API files to see if anything changed unexpectedly.

[Seadragon91]

I tested this changes by comparing the generated Bindings.cpp. The only difference is the line with the time stamp. Is that enough as check?

[madmaxoft]

Yes, that's a good enough check.

[madmaxoft]

I'm not too sure about the types with names. What is that for? And does the ToLua runtime lib support it?

[peterbell10]

@madmaxoft
Sorry but I'm not sure what you mean by "types with names".

[madmaxoft]

Sorry, I meant types with spaces.

[peterbell10]

Oh that's simple enough, it just means you can write

enum Foo : unsigned char {};

[madmaxoft]

Oh, so it's only parser-side, not in the runtime.

[madmaxoft]

I think it's safe to say that this copyright is not what you meant, unless you are secretly Waldemar :)

[peterbell10]

Well it was all just copied from enumerate.lua with some minor tweaks. I haven't looked at the license though.

[peterbell10]

Is the way it is now OK? If not I might need a bit of help for what to put.

[madmaxoft]

Good enough for me.

[peterbell10]

Is there anything stopping this from getting merged?

[Seadragon91]

Ah should have done a squash merge...

[madmaxoft]

Is there any reason why the ScopedEnum is created anew, instead of putting it inside the regular Enum?

I'm trying to fix in-class enum handling and now there's duplicate code.

[peterbell10]

The main differences are the extra namespace qualifier to access the enum, and in classScopedEnum:register where there is an extra module output and the strong typing means the need for extra static_casts. I suppose it could be rewritten so ScopedEnum is just a container for Enumerate and move the static_casts into Enumerate:register.

Though I don't think it's related to where the enum is declared; could you explain the issue with in-class enums?

[madmaxoft]

I guess I'll rewrite it like that.

The problem with in-class enums is when two classes each have an enum with the same name:

class cClassA
{
  enum eType { ... };
};

class cClassB
{
  enum eType { ... };
},

The parser doesn't use fully-qualified type names for some parts and ends up generating invalid code or mixing up the values.

[Seadragon91]

@peterbell10 If you look into the generated Bindings.cpp for eMaterial. That's the enum for the boat materials and they can be accessed over the class name, e.g. cBoat.btOak. The problem is now that the enum range check is not generated correctly, it's missing the class name.