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]
    :P
    Yeah I definitely hope we're not big enough for that :D
    I guess I'll just go start merging PRs then
    Shall we get MaikKlein/ash#597 in first and keep that as the last non-breaking commit in the event that we'd like some backports?
    Ralith
    @ralith:ralith.com
    [m]
    sgtm
    Marijn
    @marijns95:matrix.org
    [m]
    You'll probably have to rebase your PR a bit then, new functions and all...
    Perhaps @MaikKlein should change the PR settings to require everything to be based off of main before we can click merge
    (That should also automatically show an "update branch" button in GH UI)
    Because then at least we'll have the CI - in particular the generator run - against main always
    Otherwise it'll only start erroring about missed generated changes after being squash-merged on top
    And so I saw the wrong 1.3.207 title (should have been .208) as I clicked merge
    Oh well :D
    Ralith
    @ralith:ralith.com
    [m]
    close enough >_>
    Marijn
    @marijns95:matrix.org
    [m]
    Happens too often tbh 😂
    Ralith
    @ralith:ralith.com
    [m]
    rebased 599, and added a second commit with some cosmetic internal cleanup
    Marijn
    @marijns95:matrix.org
    [m]
    Nice touch, did I really go against the status quo and use the function call for 1.3 only?
    I only see .fp_v1_3() calls, nothing else 🙈
    Marijn
    @marijns95:matrix.org
    [m]
    I think we've got everything. 592 is not ready (your input is appreciated there too Ralith) and 595 can land another time for ash-window
    I'll try to publish a new release tomorrow unless anything else comes up
    Ralith
    @ralith:ralith.com
    [m]
    sgtm
    Marijn
    @marijns95:matrix.org
    [m]
    Also just dropped some branches related to bors or associated with a closed PR. @MaikKlein Anything else we can remove from https://github.com/MaikKlein/ash/branches/all?
    Ralith
    @ralith:ralith.com
    [m]
    there's a toggle to auto-delete branches, very nice to enable
    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?