Rollup of 8 pull requests
Successful merges:
- #103418 (Add `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` to future-incompat report)
- #106113 (llvm-wrapper: adapt for LLVM API change)
- #106144 (Improve the documentation of `black_box`)
- #106578 (Label closure captures/generator locals that make opaque types recursive)
- #106749 (Update cc to 1.0.77)
- #106935 (Fix `SingleUseLifetime` ICE)
- #107015 (Re-enable building rust-analyzer on riscv64)
- #107029 (Add new bootstrap members to triagebot.toml)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add new bootstrap members to triagebot.toml
```@ozkanonur``` if you want to be assigned to review PRs too, just post a message to this thread.
Should a `T-bootstrap` label be created, since `src/tools/tidy` is assigned to the `bootstrap` members, but labeled `A-testsuite` (and not `A-bootstrap`) ?
cc ```@jyn514```
Re-enable building rust-analyzer on riscv64
It was disabled in #75103 due to an LLVM bug, but followup comments have
confirmed that it builds fine on Fedora with LLVM 15.
r? ```@Mark-Simulacrum```
cc ```@matklad``` ```@davidlt```
Improve the documentation of `black_box`
There don't seem to be many great resources on how `black_box` should be used, so I added some information here
llvm-wrapper: adapt for LLVM API change
No functional changes intended.
The LLVM commit e6b02214c6 added `TargetExtTyID` to the `TypeID` enum. This adapts `RustWrapper` accordingly.
Add `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` to future-incompat report
See https://github.com/rust-lang/rust/issues/79813 for a discussion of this lint. This has been warn-by-default for over a year, so adding it to the future-incompat report should help to find libraries that haven't yet updated.
Revert "Make PROC_MACRO_DERIVE_RESOLUTION_FALLBACK a hard error"
This reverts commit 7d82cadd97 aka PR #84022
I am doing this to buy us some time with respect to issue #106337 w.r.t. the 1.67 release.
To retrieve these flags rustdoc currently has to mass decode full attributes for items in the whole crate tree, so it's better to pre-compute it in advance.
This is especially for short-term performance of https://github.com/rust-lang/rust/pull/107054 because resolver cannot use memoization of query results yet.
Remap paths in UI tests by default
If you think this needs further discussions / something RFC-like, please let me know the best forum for that.
This PR runs UI tests with a remapped "src base" directory by default.
Why? Because some UI tests currently depend on the length of the absolute path to the `src/test/ui` directory. Remapping makes the tests independent of the absolute path.
The path to the source file (which is absolute on CI) is part of the type name of closures. `rustc` diagnostic output depends on the length of type names (long type names are truncated). So a long absolute path leads to long closure type names, which leads to truncation and changed diagnostics.
(I initially tried just disabling type name truncation, but that made some error messages stupid long (thousands of characters, IIRC)).
Additional changes:
* All boolean `compiletest` directives now support explicit `no-` versions to disable them.
* Adapt existing tests when necessary:
* Disable remapping for individual tests that fail with it enabled (when there's no obvious alternative fix).
* For tests that already check something remapping related switch to the new option unless we gain something significant by keeping the manual remap.
Passed Windows CI in https://github.com/rust-lang/rust/actions/runs/3933100590
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`
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.
