Ronan
Ronan
I squashed #8110 and #8111 down to one commit each. As for your comment that the two PR can be done in one PR: is that possible? We can only...
>As per my comment in 8085: _"I think it'll be easier both for you and me to open a single PR for docking (close the master one), but with commit...
I also have some other changes (SuperRonan/imgui@5b9a62f2cf10669e9c24c0dc40f208f6353d3341) ready to be pushed (ability to control viewports format / present mode, but without color correction), so this might be considered a new...
It was moved to `ImGui_ImplVulkan_CreateDeviceObjects()` as you suggested.
Oh yes indeed the block is also in `ImGui_ImplVulkan_Init`, merging error. You can remove it from `ImGui_ImplVulkan_Init`
> In the `cpp` target, `String` is a class (IIRC it maps to `Slang::String`) and `NativeString` maps directly to `const char*`. Breaking `NativeString`s would be a big deal to me,...
I am investigating the issue with the mandatory inlining that is not performed in C++ that blocks using `getStringHash(String)` in C++ (already mentioned in #2544). I feel like the `[__unsafeForceInlineEarly]`...
I have another issue with debug information. It generates constructs that: - Can be emitted in the target language, but are invalid: ``` // in HLSL struct Tuple_0 { StringLiteral...
`String` and `NativeString` should not be convertible to `ShortString`, because the content of `ShortString` must be known at compile time.
The decoder to get the utf32 content of the string can be done outside of the compiler? In "plain" slang code in the core module.