ir: Add an option to generate an empty, default constructor for tagged enums.

[emilio]

This allows to clean up a pattern that has been showing up lately, see
occurrences of:

https://searchfox.org/mozilla-central/rev/9775cca0a10a9b5c5f4e15c8f7b3eff5bf91bbd0/servo/ports/geckolib/cbindgen.toml#329

[emilio]

r? @gankro

[Gankra]

i'm completely unfamiliar with the issue and having trouble making sense of it, can you expand on this? what types don't we support? i'm not familiar with the concept of "trivially constructible".

[emilio]

So the issue is the following. Simplified.

This builds, as expected:

#include <cstdint>
#include <new>

struct TypeWithDestructor {
    uint8_t field;
    // ~TypeWithDestructor() {}
};

struct TaggedUnion {
    static TaggedUnion Create(const TypeWithDestructor& a) {
        TaggedUnion ret;
        ret.type = 0;
        new (&ret.foo) TypeWithDestructor(a);
        return ret;
    }

    uint8_t type;
    union {
        TypeWithDestructor foo;
    };
};

If you uncomment the destructor, then it doesn't, because C++ will implicitly delete the default constructor of TaggedUnion.

Since all we want is a default constructor that doesn't initialize anything, so that Create() does the right thing, a private default constructor serves this purpose. It also avoids people accidentally creating uninitialized structs themselves, which is a win-win.

[emilio]

The final simplified example for cbindgen would be:

#include <cstdint>
#include <new>

struct TypeWithDestructor {
    uint8_t field;
    ~TypeWithDestructor() {}
};

struct TaggedUnion {
    static TaggedUnion Create(const TypeWithDestructor& a) {
        TaggedUnion ret;
        ret.type = 0;
        new (&ret.foo) TypeWithDestructor(a);
        return ret;
    }

    private:
    TaggedUnion() {}
    
    public:
    ~TaggedUnion() { /* cbindgen-generated */ }

    uint8_t type;
    union {
        TypeWithDestructor foo;
    };
};

With nicer enum types and such of course.

[Gankra]

Is the claim that this is dangerous just incorrect? Adding a private default constructor doesn't actually change the ABI in any meaningful way, does it? It just enables you to add destructors that do mess up the ABI..?

[emilio]

Adding constructors changes the ABI of return types in MSVC: https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=vs-2019#return-values

To return a user-defined type by value in RAX, it must have a length of 1, 2, 4, 8, 16, 32, or 64 bits. It must also have no user-defined constructor, destructor, or copy assignment operator; no private or protected non-static data members; no non-static data members of reference type; no base classes; no virtual functions; and no data members that do not also meet these requirements. (This is essentially the definition of a C++03 POD type. Because the definition has changed in the C++11 standard, we don't recommend using std::is_pod for this test.)

[emilio]

And yeah I wish I didn't know this :)

[emilio]

@Gankra anything blocking this? Thanks!

[Gankra]

FRIG

i swear i keep hallucinating that i said yes to this

pls ship it