Use UnordMap and UnordSet for id collections (DefIdMap, LocalDefIdMap, etc)
This PR changes the `rustc_data_structures::define_id_collections!` macro to use `UnordMap` and `UnordSet` instead of `FxHashMap` and `FxHashSet`. This should account for a large portion of hash-maps being used in places where they can cause trouble.
The changes required are moderate but non-zero:
- In some places the collections are extracted into sorted vecs.
- There are a few instances where for-loops have been changed to extends.
~~Let's see what the performance impact is. With a bit more refactoring, we might be able to get rid of some of the additional sorting -- but the change set is already big enough. Unless there's a performance impact, I'd like to do further changes in subsequent PRs.~~
Performance does not seem to be negatively affected ([perf-run here](https://github.com/rust-lang/rust/pull/106977#issuecomment-1396776699)).
Part of [MCP 533](https://github.com/rust-lang/compiler-team/issues/533).
r? `@ghost`
Use UnordMap and UnordSet for id collections (DefIdMap, LocalDefIdMap, etc)
This PR changes the `rustc_data_structures::define_id_collections!` macro to use `UnordMap` and `UnordSet` instead of `FxHashMap` and `FxHashSet`. This should account for a large portion of hash-maps being used in places where they can cause trouble.
The changes required are moderate but non-zero:
- In some places the collections are extracted into sorted vecs.
- There are a few instances where for-loops have been changed to extends.
~~Let's see what the performance impact is. With a bit more refactoring, we might be able to get rid of some of the additional sorting -- but the change set is already big enough. Unless there's a performance impact, I'd like to do further changes in subsequent PRs.~~
Performance does not seem to be negatively affected ([perf-run here](https://github.com/rust-lang/rust/pull/106977#issuecomment-1396776699)).
Part of [MCP 533](https://github.com/rust-lang/compiler-team/issues/533).
r? `@ghost`
Fix spelling inconsistence of `mdBook`
I was reading both [mdBook Documentation](https://rust-lang.github.io/mdBook/) and [The Clippy Book](https://doc.rust-lang.org/nightly/clippy/development/infrastructure/book.html#the-clippy-book) and felt that it's easier to read to unify the notation of `mdBook`.
- \[ ] Followed [lint naming conventions][lint_naming]
- \[ ] Added passing UI tests (including committed `.stderr` file)
- \[x] `cargo test` passes locally
- \[ ] Executed `cargo dev update_lints`
- \[ ] Added lint documentation
- \[x] Run `cargo dev fmt`
----
changelog: none
There is a number of APIs that answer dominance queries. Previously they
were named either "dominates" or "is_dominated_by". Consistently use the
"dominates" form.
No functional changes.
Rollup of 9 pull requests
Successful merges:
- #104154 (Change `bindings_with_variant_name` to deny-by-default)
- #104347 (diagnostics: suggest changing `s@self::{macro}`@::macro`` for exported)
- #104672 (Unify stable and unstable sort implementations in same core module)
- #107048 (check for x version updates)
- #107061 (Implement some more new solver candidates and fix some bugs)
- #107095 (rustdoc: remove redundant CSS selector `.sidebar .current`)
- #107112 (Fix typo in opaque_types.rs)
- #107124 (fix check macro expansion)
- #107131 (rustdoc: use CSS inline layout for radio line instead of flexbox)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
fix check macro expansion
If the only argument to `check!` is the module name I get this error:
```
error: expected expression, found `,`
--> src/tools/tidy/src/main.rs:63:42
|
57 | / macro_rules! check {
58 | | ($p:ident $(, $args:expr)* ) => {
59 | | drain_handles(&mut handles);
60 | |
... |
63 | | $p::check($($args),* , &mut flag);
| | ^ expected expression
... |
69 | | }
70 | | }
| |_________- in this expansion of `check!`
...
117 | check!(hey);
| ----------- in this macro invocation
```
This change makes it so commas are added only when there are `args`.
r? ```@albertlarsan68```
Implement some more new solver candidates and fix some bugs
First, fix some bugs:
1. `IndexVec::drain_enumerated(a..b)` does not give us an iterator of index keys + items enumerated from `a..b`, but from `0..(b-a)`... That caused a bug. See first commit for the fix.
2. Implement the `_: Trait` ambiguity hack. I put it in assemble, let me know if it should live elsewhere. This is important, since we otherwise consider `_: Sized` to have no solutions, and nothing passes!
3. Swap `Ambiguity` and `Unimplemented` cases for the new solver. Sorry for accidentally swapping them 😄
4. Check GATs' own predicates during projection confirmation.
Then implement a few builtin traits:
5. Implement `PointerSized`. Pretty independent.
6. Implement `Fn` family of traits for fnptr, fndef, and closures. Closures are currently broken because `FulfillCtxt::relationships` is intentionally left unimplemented. See comment in the test.
r? ```@lcnr```
check for x version updates
This PR adds a check to tidy to assert that the installed version of `x` is equal to the version in `src/tools/x/Cargo.toml`. It checks the installed version of `x` by parsing the output of `cargo install --list` (as an option proposed in this [issue](https://github.com/rust-lang/rust/issues/106469)).
It does not warn if `x` has not yet been installed, on the assumption that the user isn't interested in using it.
Unify stable and unstable sort implementations in same core module
This moves the stable sort implementation to the core::slice::sort module. By virtue of being in core it can't access `Vec`. The two `Vec` used by merge sort, `buf` and `runs`, are modelled as custom types that implement the very limited required `Vec` interface with the help of provided allocation and free functions. This is done to allow future re-use of functions and logic between stable and unstable sort. Such as `insert_head`.
This is in preparation of #100856 and #104116. It only moves code, it *doesn't* change any of the sort related logic. This unlocks the ability to share `insert_head`, `insert_tail`, `swap_if_less` `merge` and more.
Tagging ````@Mark-Simulacrum```` I hope this allows progress on #100856, by moving `merge_sort` here I hope future changes will be easier to review.
Change `bindings_with_variant_name` to deny-by-default
Changed the `bindings_with_variant_name` lint to deny-by-default and fixed up the affected tests.
Addresses #103442.
[master] Update git2 version
This PR bumps the version of the `git2` and `libgit2-sys` crates to pull in fixes for https://github.com/rust-lang/git2-rs/security/advisories/GHSA-m4ch-rfv5-x5g3.
This **does not fix any security vulnerability**: Cargo is already protected thanks to the fixes we implemented as part of CVE-2022-46176. The only purpose of this PR is to avoid dependency scanners from flagging vulnerabilities.
Update cargo
3 commits in 50eb688c2bbea5de5a2e8496230a7428798089d1..985d561f0bb9b76ec043a2b12511790ec7a2b954
2023-01-19 10:09:05 +0000 to 2023-01-20 14:39:28 +0000
- Stabilize sparse-registry (rust-lang/cargo#11224)
- Wrapper type for data that should never be logged (rust-lang/cargo#11545)
- Add semver rule for lints (rust-lang/cargo#11596)
r? `@ghost`
Include sanitizers supported by LLVM on s390x (asan, lsan, msan, tsan)
in the target definition, as well as in the compiletest supported list.
Build sanitizer runtime for the target. Enable sanitizers in the CI.
3 commits in 50eb688c2bbea5de5a2e8496230a7428798089d1..985d561f0bb9b76ec043a2b12511790ec7a2b954
2023-01-19 10:09:05 +0000 to 2023-01-20 14:39:28 +0000
- Stabilize sparse-registry (rust-lang/cargo#11224)
- Wrapper type for data that should never be logged (rust-lang/cargo#11545)
- Add semver rule for lints (rust-lang/cargo#11596)