Mike Hommey

I don't remember where I read it, but I was led to believe that this extension + rust-analyzer was the endgame (that's why I gave it a try). Did that...

So at this point, here is what I have in private branches: - Tweaks to tool_gnu to make it require "MSYS2 MinGW 64-bit" only, and the ability to generate both...

Oh, forgot to mention in the list of differences: LLVM sets all the ordinal/hints to 0.

I refreshed the commits mentioned in https://github.com/microsoft/windows-rs/issues/1964#issuecomment-1227046538 with rebased versions on top of current master, but they will obviously need another refresh after next metadata update. Anyways, thoughts, @riverar, @kennykerr?

Well, currently, the `@number` is added for all symbols, so there's at least a part of the problem on this side. I can share the full list I have, but...

Full list here: https://gist.github.com/glandium/395e52e494b56094184ab8d898340d89

ICU is only a small part of the list, though.

Shouldn't this stay open for the part where windows-rs will have to be adjusted for cdecl functions? (or are cdecl functions filtered-out?)

#5416 has a discussion about lists, and I can see how that wouldn't work, but I don't see open-ended keys being a huge problem.

I stumbled upon `padding_needed_for` and `pad_to_align`, and it seems they are being too cautious. That is, per https://doc.rust-lang.org/nightly/src/core/alloc.rs.html#95, `layout.size()` is always