Rollup of 8 pull requests
Successful merges:
- #111917 (Simplify duplicate checks for mir validator)
- #112008 (Fix incorrect documented default bufsize in bufreader/writer)
- #112825 (Don't call `type_of` on TAIT in defining scope in new solver)
- #113164 (Add a regression test for #109054)
- #113318 (Revert "alloc: Allow comparing Boxs over different allocators", add regression test)
- #113397 (Prefer object candidates in new selection)
- #113419 (Avoid calling item_name for RPITIT)
- #113421 (Do not assert >1 RPITITs on collect_return_position_impl_trait_in_trait_tys)
r? `@ghost`
`@rustbot` modify labels: rollup
Do not assert >1 RPITITs on collect_return_position_impl_trait_in_trait_tys
Fixes#113403
Assert on collect_return_position_impl_trait_in_trait_tys is not correct when we call it from type_of(GAT). The included test is an example of a situation that collector collects 0 types.
r? `@compiler-errors`
Prefer object candidates in new selection
`dyn Any` shouldn't be using [this implementation](https://doc.rust-lang.org/std/any/trait.Any.html#impl-Any-for-T) during codegen.
Prefer object candidates over other candidates, except for other object candidates.
Revert "alloc: Allow comparing Boxs over different allocators", add regression test
Temporary fix for #113283
Adds a test to fix the regression introduced in 001b081cc1 and revert that commit. The test fails without the revert.
Don't call `type_of` on TAIT in defining scope in new solver
It's *never* productive to call `consider_auto_trait_candidate` on a TAIT in the defining scope, since it will always lead to a query cycle since we call `type_of` on the TAIT. So let's just don't.
I've reserved this behavior just to `SolverMode::Normal` just to avoid any future problems, since this is *technically* incomplete since we're discarding a candidate that could *theoretically* apply. But given such candidate assembly *always* leads to a query cycle, I think it's relatively low risk, and I could be convinced otherwise and make this apply to both solver mode. I assume it's far less likely to be encountered in coherence, though.
This is much more likely to encounter in the new solver, though it can also be encountered in the old solver too, so I'm happy to discuss whether this new behavior we even want in the first place...
I encountered this in a couple of failing UI tests:
* `tests/ui/type-alias-impl-trait/issue-62000-associate-impl-trait-lifetimes.rs`
* `tests/ui/type-alias-impl-trait/issue-93411.rs`
r? `@lcnr`
Use `llvm-config` instead of `download-ci-llvm` in PGO script
This should avoid CI breakage when the LLVM stamp is updated, and also it will avoid an unnecessary LLVM download from CI.
r? `@jyn514`
Dont ICE for `dyn* Trait: Trait` (built-in object) goals during selection in new trait solver
We were ICEing too eagerly during selection for `dyn*` goals -- both for dyn unsizing candidates and for built-in object candidates. The former should only be performed on `dyn` objects, but the latter are totally fine.
fix compiletest crash
### Motivation
When running compiler-tests locally for the `wasm32` platform, one test repeatedly crashed. It does not crash on the CI, only locally. Investigation shows that the `compiletest` itself crashes
> panicked-at-attempt-to-subtract-with-overflow
```rust
let mut head = replace(bytes, Vec::new());
let mut middle = head.split_off(HEAD_LEN);
// The following line will panic
let tail = middle.split_off(middle.len() - TAIL_LEN).into_boxed_slice();
let skipped = new_len - HEAD_LEN - TAIL_LEN;
```
### Background
The code in question collects the output of a process. Small output is kept completely, but larger output is kept only partially: the first 160 kB and the last 256 kB.
The code that performs this split crashes if the data size is less than 416 kB. There is an early out based on the "filtered" length, but it is possible that the filtered length is greater than the real length. It seems that this code was written with the assumption that the filtered length is larger than the real length, which is not true in general.
When running CI tests locally using `src/ci/docker/run.sh`, the filtered folder is `/checkout`, which is shorter than the placeholder length of 32 bytes.
### Note
This PR should not change any behaviour. It only adds an early our for a case which will definitely crash (at least if compiletest is build with integer checks).
Note that an early out makes sense here: If the real data is too small, it does not sense to split it.
Fix the tests-listing-format-json test on Windows
tests/ui/test-attrs/tests-listing-json-format.rs was failing on Windows because each path in the json-formatted output contained "\\\\" instead of "\\". `runtest::TestCx::normalize_output` already checks the compile flags for json-related arguments to handle this case, so I added an equivalent check for the new run flag.
Move `TyCtxt::mk_x` to `Ty::new_x` where applicable
Part of rust-lang/compiler-team#616
turns out there's a lot of places we construct `Ty` this is a ridiculously huge PR :S
r? `@oli-obk`
Rollup of 9 pull requests
Successful merges:
- #111119 (style-guide: Add chapter about formatting for nightly-only syntax)
- #112791 (llvm ffi: Expose `CallInst->setTailCallKind`)
- #113145 (style-guide: Document newline rules for assignment operators)
- #113163 (Add a regression test for #112895)
- #113332 (resolve: Use `Interned` for some interned structures)
- #113334 (Revert the lexing of `c"…"` string literals)
- #113350 (Fix the issue of wrong diagnosis for extern pub fn)
- #113371 (Fix submodule handling when the current branch is named after a tag)
- #113384 (style-guide: Clarify grammar for small patterns (not a semantic change))
r? `@ghost`
`@rustbot` modify labels: rollup
style-guide: Clarify grammar for small patterns (not a semantic change)
The grammar as written feels ambiguous and confusing, in large part
because it uses square brackets and commas in the names of
non-terminals. Rewrite it to avoid symbols in the names of
non-terminals, and to instead wrap terminals in backquotes.
Also rename "smallntp" to "small_no_tuple" to make it self-describing.
Fix submodule handling when the current branch is named after a tag
If:
1. The current branch has the same name as git tag, and
2. The current branch is set to track a remote other than `origin`, and
3. We try to update a submodule
then we'll get the following error:
```
; x c
Updating submodule src/doc/reference
remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
fatal: 'personal' does not appear to be a git repository
fatal: Could not read from remote repository.
```
The problem is that 1. causes `git symbolic-ref --short HEAD` to try and disambiguate the branch from the tag using `heads/branch-name`, which breaks a previous workaround for a bug in `git submodule update` that uses the wrong remote.
Adapt the workaround to strip `heads/` from the output.
Revert the lexing of `c"…"` string literals
Fixes \[after beta-backport\] #113235.
Further progress is tracked in #113333.
This PR *manually* reverts parts of #108801 (since a git-revert would've been too coarse-grained & messy)
and git-reverts #111647.
CC `@fee1-dead` (#108801) `@klensy` (#111647)
r? `@compiler-errors`
`@rustbot` label F-c_str_literals beta-nominated
style-guide: Document newline rules for assignment operators
The style guide gives general rules for binary operators including
assignment, and one of those rules says to put the operator on the
subsequent line; the style guide needs to explicitly state the exception
of breaking *after* assignment operators rather than before.
This is already what rustfmt does and what users do; this fixes the
style guide to match the expected default style.
