suits me, it's a big rebase hazard so it'd be nice not to have it lurking
Then over time, as nonbreaking stuff appears, I'll create a
0.37-stable branch and start cherry-picking stuff (merged to master first) to it that we'd like for a patch release
And then see if we can do a couple months without a breaking release - but I'm still more than happy to start with
0.38-pre.X releases as soon as we have some tangible UI changes ready we'd like to throw in the wild
fwiw I'm skeptical that it can ever be sound to assume ABI-equivalence between
struct Foo { ..., length: usize, ptr: *const T, ... } and struct Foo { ..., field: (usize, *const T), ... }
And we'd have the edge-case of one length value being shared by multiple pointers, so it might not be worth pursuing this at all
maybe if we explicitly restrict targets to those for which that is true, which might plausibly be all the important ones, but it's an unsettling prospect
right
the current approach is pleasantly uniform
yeah, I'm inclined to pursue that in a separate PR; no need to make things too monolithic
there's even a case to be made for splitting the existing inlining out entirely, but eh :P
I think the bulk of the remaining inlining work is to go through all the handwritten stuff, which will be tedious
though I've gotten a ton of mileage out of cheeky regexps so far
Until needing some very specific stuff with multiple statements, where it all fell apart :D
Regarding ABI compliance, I guess the only issue here is alignment?
(/me doesn't remember if
sizeof(usize) == sizeof(*const) in Rust)
(Same for their alignment)
Right, usize is literally defined as
The pointer-sized unsigned integer type.
But it seems unlikely that their alignment is forced to be the same, which could indeed cause ABI differences between the two
the main issue in my mind is that structs are not semantically transparent in C ABI; placing fields in a struct can in principle change how they interact with the layout algorithm all on its own
On top of your PR, with a literal
return None; coded at the beginning of derive_setters() and regenerating:$ hyperfine -p 'cargo clean -p ash' 'cargo b -p ash'
Benchmark 1: cargo b -p ash
Time (mean ± σ): 5.174 s ± 0.027 s [User: 5.914 s, System: 0.319 s]
Range (min … max): 5.101 s … 5.193 s 10 runs
So removing setters entirely is only ~550ms, and that's going to be less when we can't omit ~half of those for having pointers/slices/other magic sauce
Curious where we're loosing out now
at a certain point we'll hit rustc issues rather than us issues, if nothing else
fiddling with setters by
&mut rather than by value; looks like the big drawback is you can't do let foo = vk::Whatever::default().bar(..).baz(..);, which seems significant
particularly as that's much less bad an idea now than it was before now that lifetimes don't get erased at the drop of a hat
@MaikKlein: Can you turn on "branch must be based off of master" in branch protection and/or enable
Always suggest updating pull request branches? We just merged a PR that wasn't based off of the recent generator changes resulting in obvious CI breakage because the new code wasn't regenerated
Easy to fix, but nice if GH can preemptively prevent it :)
ah, never mind, this is an unrelated issue with the (non-cargo) build system I'm using
And keeping up with it so far
hey, i'm trying to define a zprepass subpass, how do I provide a 'nullptr' to the GraphicsPipelineCreateInfoBuilder.color_blend_state()?
I think this is the default state if you are using ash::vk::GraphicsPipelineCreateInfo::builder. Otherwise you can use std::ptr::null() as the linked source does :)