If it wasn't for a handwritten changelog being a bit easier to redact (ie. omit internal changes, clean up PR titles), I'd go for GH automatically generating it from commits when "publishing" a release on a tag
fortunately low stakes
Perhaps it really is time to start actively maintaining a
0.37-stable branch that we'll either directly merge non-breaking changes into, or manually cherry-pick merged PRs to?
This one is on me though, the last (also breaking, for extremely minor things) Ash release felt ages ago but it's only been just over a month 😅
And in the event that people like to see their breaking changes published to crates.io, but we don't yet feel like we have enough material for yet another breaking release, we can publish a prerelease for the next version while prolonging the non-breaking patch cycle much longer
Regarding cherry-picking though, this may end up in conflicts real fast given that we have lots of autogenerated code that will get out of sync
So we might as well create a special
breaking label and keep (as maintainers) rebase feature PRs until we merge them all at once (into / on top of the stable branch)
dealing with the generated code isn't too bad, you just ignore conflicts there and rerun the generator
Still cumbersome when rebasing (would love the ci to run on everything individually), really don't like large merge commits with lots of conflict resolution (unless it's exclusively generated changes, can make an exception for that)
Hey, I'm just getting back into using ash after a long time away, and I notice that there's the new const names that use the CStr::from_bytes_with_nul_unchecked which requires a feature flag in the attributes of the crate. Is there something I have to do in my local project to use it? Or is this a problem with the published 0.37 version not having the feature flag enabled?
$ rustc --version
rustc 1.56.1 (59eed8a2a 2021-11-01)
ah, looks like it's not fully updated since 1.59 is the most updated now
hmm
ah, I see, the project was old enough that I had not yet updated the edition from the 2018 edition
@IGJoshua: Too late for your situation now, but hopefully this is going to help in the future: MaikKlein/ash#604
I also wasn't actively aware that
from_bytes_with_nul_unchecked got bumped to const only in 1.59, quite bummed that we didn't get to know that up-front
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