Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Marijn
    @marijns95:matrix.org
    [m]
    Would be great to have for the merged PRs indeed
    Is a blessing on some other repos
    Ralith
    @ralith:ralith.com
    [m]
    opened KhronosGroup/Vulkan-Docs#1803 for the upstream issue
    fewer cases than I'd feared
    Marijn
    @marijns95:matrix.org
    [m]
    That's manageable
    Looks like it didn't make it into the .209 update this morning though :)
    Ralith
    @ralith:ralith.com
    [m]
    -Z time-passes output items more than 100ms:
    time:   0.104; rss:  695MB ->  696MB (   +1MB)    crate_lints
    time:   0.107; rss:  457MB ->  483MB (  +25MB)    coherence_checking
    time:   0.109; rss:  817MB ->  822MB (   +6MB)    partition_and_assert_distinct_symbols
    time:   0.171; rss:   43MB ->   93MB (  +50MB)    total
    time:   0.177; rss:  696MB ->  697MB (   +0MB)    privacy_checking_modules
    time:   0.178; rss:  892MB ->  895MB (   +4MB)    encode_query_results
    time:   0.195; rss:  255MB ->  290MB (  +35MB)    late_resolve_crate
    time:   0.195; rss:  892MB ->  894MB (   +2MB)    incr_comp_serialize_result_cache
    time:   0.195; rss:  892MB ->  894MB (   +3MB)    incr_comp_persist_result_cache
    time:   0.195; rss:  892MB ->  894MB (   +3MB)    serialize_dep_graph
    time:   0.199; rss:  695MB ->  696MB (   +1MB)    lint_checking
    time:   0.202; rss:  549MB ->  557MB (   +8MB)    item_types_checking
    time:   0.231; rss:  608MB ->  611MB (   +3MB)    match_checking
    time:   0.237; rss:  252MB ->  290MB (  +38MB)    resolve_crate
    time:   0.318; rss:  608MB ->  613MB (   +5MB)    misc_checking_2
    time:   0.381; rss:  393MB ->  412MB (  +18MB)    misc_checking_1
    time:   0.413; rss:  412MB ->  457MB (  +45MB)    type_collecting
    time:   0.511; rss:   56MB ->  252MB ( +196MB)    expand_crate
    time:   0.511; rss:   56MB ->  252MB ( +196MB)    macro_expand_crate
    time:   0.515; rss:  290MB ->  407MB ( +117MB)    hir_lowering
    time:   0.662; rss:  800MB ->  817MB (  +17MB)    monomorphization_collector_graph_walk
    time:   0.685; rss:  682MB ->  697MB (  +15MB)    misc_checking_3
    time:   0.781; rss:   52MB ->  290MB ( +238MB)    configure_and_expand
    time:   0.805; rss:  483MB ->  549MB (  +66MB)    wf_checking
    time:   0.861; rss:  824MB ->  894MB (  +70MB)    codegen_to_LLVM_IR
    time:   1.636; rss:  697MB ->  824MB ( +127MB)    generate_crate_metadata
    time:   1.885; rss:  557MB ->  608MB (  +51MB)    item_bodies_checking
    time:   2.233; rss:  613MB ->  680MB (  +67MB)    MIR_borrow_checking
    time:   3.466; rss:  412MB ->  608MB ( +196MB)    type_check_crate
    time:   3.678; rss:  872MB ->  894MB (  +22MB)    LLVM_passes(crate)
    time:   4.033; rss:  824MB ->  894MB (  +70MB)    codegen_crate
    time:  14.673; rss:   40MB ->  102MB (  +62MB)    total
    interesting that codegen is so large, given the general absence of meaningful logic in ash
    Marijn
    @marijns95:matrix.org
    [m]
    Thats's really curious
    And macro expansion is relatively cheap
    Anyway, shall we get 0.37 out the door and start looking more into these?
    Ralith
    @ralith:ralith.com
    [m]
    sgtm
    Marijn
    @marijns95:matrix.org
    [m]
    Heh, just as you approve I find some more noise in the changelog
    Here goes the CI again...
    And more...
    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
    Ralith
    @ralith:ralith.com
    [m]
    yeah, mixed bag
    fortunately low stakes
    Marijn
    @marijns95:matrix.org
    [m]
    Ralith: I'm also starting to get internal complaints about performing breaking ash releases relatively often for "minor" improvements
    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 😅
    Marijn
    @marijns95:matrix.org
    [m]
    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)
    Ralith
    @ralith:ralith.com
    [m]
    dealing with the generated code isn't too bad, you just ignore conflicts there and rerun the generator
    Marijn
    @marijns95:matrix.org
    [m]
    Fair enough, same for merging PRs later
    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)
    Joshua Suskalo
    @IGJoshua
    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?
    Ralith
    @ralith:ralith.com
    [m]
    is your rustc up to date?
    Joshua Suskalo
    @IGJoshua
    I think so, I'm running arch and I've updated all my packages recently. Do I have to do some cargo command to ensure it's fully updated?
    $ 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
    Joshua Suskalo
    @IGJoshua
    sorry about the trouble. Looks like I just needed to do a rustup update
    Marijn
    @marijns95:matrix.org
    [m]
    @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
    Marijn
    @marijns95:matrix.org
    [m]
    Ralith: Should we just go ahead and merge your breaking PR straight to master already?
    Ralith
    @ralith:ralith.com
    [m]
    suits me, it's a big rebase hazard so it'd be nice not to have it lurking
    Marijn
    @marijns95:matrix.org
    [m]
    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
    Ralith
    @ralith:ralith.com
    [m]
    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), ... }
    Marijn
    @marijns95:matrix.org
    [m]
    Fair enough, I hadn't given that much thought just yet
    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
    Ralith
    @ralith:ralith.com
    [m]
    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
    Marijn
    @marijns95:matrix.org
    [m]
    Are you done with #602 btw? As in, #[inline]'ing the rest of the functions shoul;d be done in a separate PR anyways?
    Ralith
    @ralith:ralith.com
    [m]
    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