SDL 3: Failed to resolve compile time constants for SDL_UINT64_C

[3xau1o]

SDL 3 has window comptime constants wrapped by SDL_UINT64_C, these are important but ignored by rust-bindgen

Source

#define SDL_WINDOW_FULLSCREEN           SDL_UINT64_C(0x0000000000000001)  
#define SDL_WINDOW_OPENGL               SDL_UINT64_C(0x0000000000000002)  
#define SDL_WINDOW_OCCLUDED             SDL_UINT64_C(0x0000000000000004) 
// many more

Expected rust binding

pub const SDL_WINDOW_FULLSCREEN: u64  = 0x0000000000000001;
pub const SDL_WINDOW_OPENGL: u64  =  0x0000000000000002;
pub const SDL_WINDOW_OCCLUDED: u64  =   0x0000000000000004; 

---

Zig is perfectly able to resolve these

const sdl = @cImport({
    @cInclude("SDL3/SDL.h");
});


pub fn main() !void {
    _ = sdl.SDL_Init(sdl.SDL_INIT_VIDEO | sdl.SDL_INIT_EVENTS;);

     const window = sdl.SDL_CreateWindow(
         "zig_sdl",
        640,
        480,
        sdl.SDL_WINDOW_RESIZABLE | sdl.SDL_WINDOW_VULKAN
    );
}

[ojeda]

This seems a duplicate of #753.

Could you please try the --clang-macro-fallback option?

Thanks!

Cc @jbaublitz

[mystise]

Can confirm from local testing that --clang-macro-fallback does bypass this issue, but instead it reveals another one:

...
pub const SDL_WINDOW_FULLSCREEN: u32 = 1;
pub const SDL_WINDOW_OPENGL: u32 = 2;
pub const SDL_WINDOW_OCCLUDED: u32 = 4;
...

The constants are defined as u32, despite the definition of SDL_UINT64_C being

#define SDL_UINT64_C(c)  c ## ULL

On most configurations (MSVC and __LP64__ use slightly different definitions), and thus the outputs should be ULL constants and thus u64

Redefining SDL_UINT64_C as (uint64_t)(c ## ULL) does not help, the output constants in the Rust generated file are still u32

Currently this doesn't actually cause any issues, because all the constants in SDL3 defined using SDL_UINT64_C actually fit within 32 bits, but the largest one is exactly 0x80000000, so the next constant that gets added won't.

[jbaublitz]

Let me refresh my working memory of this PR, but as I remember, the Clang API specifically represented these constants as an integer data type without a length encoded. If the Clang API does not actually keep track of integer length for constants that are being evaluated in this context (e.g. integers that may have a length specification in the expression but are without a type binding), there may not be a lot we can do on our side without some additional help from the Clang API. We are relying on Clang to report the type and if they do not, there's no straightforward way for us to guess how big the integer type should be.

[mystise]

Ah that's unfortunate. So by my understanding, if clang doesn't provide the ULL specifier in the API in some way, that means fixing this properly would have to wait until non-fallback mode can parse and interpret function-like macros?

As stated, for now fallback mode works with this particular use case, since all current uses of this macro fall within u32.

In the future, it might be nice if something like --default-macro-constant-type (in bindgen-cli, I don't know what the equivalent function is in bindgen's Rust API) could be expanded to allow u64 instead of just signed vs unsigned, or maybe an additional flag to tag a type override per macro item?

[jbaublitz]

Ah that's unfortunate. So by my understanding, if clang doesn't provide the ULL specifier in the API in some way, that means fixing this properly would have to wait until non-fallback mode can parse and interpret function-like macros?

Arguably, it would have to wait until the Clang API provides width information for literals as opposed to a generic integer specification. That applies to the fallback code and the non-fallback code as they are both using the same Clang API and are bound by the same restrictions.

As stated, for now fallback mode works with this particular use case, since all current uses of this macro fall within u32.

In the future, it might be nice if something like --default-macro-constant-type (in bindgen-cli, I don't know what the equivalent function is in bindgen's Rust API) could be expanded to allow u64 instead of just signed vs unsigned, or maybe an additional flag to tag a type override per macro item?

If you're interested in something like this, I think a new issue would absolutely be welcome. @ojeda and @pvdrz are generally pretty open to improving the corner cases and it sounds like there may still be a way to make this better.

[3xau1o]

given that --clang-macro-fallback solved the main issue probably it's a good idea to open a new one for the u32/u64 types