Improve `skip_binder` usage during FlagComputation
It looks like there was previously a bug around `ExistentialPredicate::Projection` here, don't know how to best trigger that one to add a regression test though.
Rollup of 10 pull requests
Successful merges:
- #77612 (BTreeMap: test invariants more thoroughly and more readably)
- #77761 (Assert that pthread mutex initialization succeeded)
- #77778 ([x.py setup] Allow setting up git hooks from other worktrees)
- #77838 (const keyword: brief paragraph on 'const fn')
- #77923 ([net] apply clippy lints)
- #77931 (Fix false positive for `unused_parens` lint)
- #77959 (Tweak ui-tests structure)
- #78105 (change name in .mailmap)
- #78111 (Trait predicate ambiguities are not always in `Self`)
- #78121 (Do not ICE on pattern that uses a binding multiple times in generator)
Failed merges:
r? `@ghost`
Trait predicate ambiguities are not always in `Self`
When reporting ambiguities in trait predicates, the compiler incorrectly assumed the ambiguity was always in the type the trait should be implemented on, and never the generic parameters of the trait. This caused silly suggestions for predicates like `<KnownType as Trait<_>>`, such as giving explicit types to completely unrelated variables that happened to be of type `KnownType`.
This also reverts #73027, which worked around this issue in some cases and does not appear to be necessary any more.
fixes#77982fixes#78055
Tweak ui-tests structure
We have some similar name dirs in ui tests, e.g. `associated-type` and `associated-types` and it can be an issue when we add a test, "which is the right place?". At a glance, it seems they can be merged into one directory so let's merge them to avoid some confusion :)
const keyword: brief paragraph on 'const fn'
`const fn` were mentioned in the title, but called "deterministic functions" which is not their main property (though at least currently it is a consequence of being const-evaluable). This adds a brief paragraph discussing them, also in the hopes of clarifying that they do *not* have any effect on run-time uses.
Assert that pthread mutex initialization succeeded
If pthread mutex initialization fails, the failure will go unnoticed unless
debug assertions are enabled. Any subsequent use of mutex will also silently
fail, since return values from lock & unlock operations are similarly checked
only through debug assertions.
In some implementations the mutex initialization requires a memory
allocation and so it does fail in practice.
Assert that initialization succeeds to ensure that mutex guarantees
mutual exclusion.
Fixes#34966.
If pthread mutex initialization fails, the failure will go unnoticed unless
debug assertions are enabled. Any subsequent use of mutex will also silently
fail, since return values from lock & unlock operations are similarly checked
only through debug assertions.
In some implementations the mutex initialization requires a memory
allocation and so it does fail in practice.
Check that initialization succeeds to ensure that mutex guarantees
mutual exclusion.
Rollup of 4 pull requests
Successful merges:
- #77877 (Use `try{}` in `try_fold` to decouple iterators in the library from `Try` details)
- #78089 (Fix issue with specifying generic arguments for primitive types)
- #78099 (Add missing punctuation)
- #78103 (Add link to rustdoc book in rustdoc help popup)
Failed merges:
r? `@ghost`
Try to make ObligationForest more efficient
This PR tries to decrease the number of allocations in ObligationForest, as well as moves some cold path code to an uninlined function.
Move `slice::check_range` to `RangeBounds`
Since this method doesn't take a slice anymore (#76662), it makes more sense to define it on `RangeBounds`.
Questions:
- Should the new method be `assert_len` or `assert_length`?
normalize substs while inlining
fixes#68347 or more precisely, this fixes the same ICE in rust analyser as veloren is pinned to a specific nightly
and had an error with the current one.
I didn't look into creating an MVCE here as that seems fairly annoying, will spend a few minutes doing so rn. (failed)
r? `@eddyb` cc `@bjorn3`
Make sure arenas don't allocate bigger than HUGE_PAGE
Right now, arenas allocate based on the size of the last chunk. It is possible for a `grow` call to allocate a chunk that is not a multiple of `PAGE`, and this size is doubled for each subsequent allocation. This means, instead of `HUGE_PAGE`, the biggest page possible is actually unknown.
This change fixes this, and also removes an unnecessary checked multiplication. It is still possible to allocate bigger than `HUGE_PAGE` pages, but this will only happen as many times as absolutely necessary.
