Ingvar Stepanyan

Hm I don't really see it as any different - they're just 2 traits in the large family of `std::fmt` traits, just like `UpperHex`, `Binary`, `Pointer` etc etc. I think...

> * Currently we pass `-O2 -all`, though it's not clear to me how much thought went into that choice. `-O2` has been chosen after careful comparisons of different modes...

FWIW I think `-g` should be fine to always keep around - if input Wasm was already stripped, it won't add anything, and if it has debug info, then it...

FWIW we already use the standard [`[DataMember(Name = "...")]`](https://learn.microsoft.com/en-us/dotnet/api/system.runtime.serialization.datamemberattribute?view=net-9.0) attribute in autogenerated C# code to preserve column names for JSON representation (which was important for BitCraft): https://github.com/clockworklabs/SpacetimeDB/blob/729dbb149599b4535c3b4d4e2fb4594be7ea448f/crates/cli/tests/snapshots/codegen__codegen_csharp.snap#L110-L119 In C# it...

That's fine by me; I don't think it will be hard to adapt tests either way.

@kazimuth I rebased this, but on the 2nd thought we shouldn't compare V9 moduledef just yet. The purpose of the original issue / of adding those tests was to verify...

Heh clearly I at least broke builds on Linux, even though it works fine on Windows. Marking as draft for now.

Updated this PR to latest definitions. Thanks to #1661 + @coolreader18's #1675, I can verify that I'm now producing correct ModuleDef as it can generate Rust sources from a C#...

> My big question is whether it would make sense to get rid of the ColumnAttrs bitfield entirely. What would you replace it with?

> The bitmask type would presumably vary between ISAs depending on the lane count One possible solution could be to instead leverage the bitvec crate which can already abstract over...