Comment out unused error codes and add description for E0316
I have added an extended description of `E0316` and commented out a bunch of unused error codes to make clear the fact that they are no longer in use. You can check for yourself with
```shell
for ec in \
E0314 E0315 E0473 E0474 E0475 E0479 E0480 E0481 \
E0483 E0484 E0485 E0486 E0487 E0488 E0489
do
if [ ! -z "`grep -r $ec compiler/* --exclude-dir=rustc_error_codes`" ]
then
echo $ec
false
fi
done
```
i.e. these error codes appear nowhere in the compiler code and thus cannot be emitted.
r? ```@GuillaumeGomez```
Default panic message should print Box<dyn Any>
Closes#86039
Prior to this patch, the panic message from running the following code would be `thread 'main' panicked at 'Box<Any>'...`
```rust
use std::panic::panic_any;
fn main() {
panic_any(42);
}
```
This patch updates the phrasing to be more consistent. It now instead shows the following panic message:
```
thread 'main' panicked at 'Box<dyn Any>', ...
```
It's a very small fix 😄
Remove rustfmt tests from top-level .gitattributes
These are tracked in src/tools/rustfmt/.gitattributes already, they
don't need to be listed twice.
r? `@ehuss` since you suggested adding them in https://github.com/rust-lang/rust/pull/82208/#issuecomment-841440199; I think it should be ok now that bors isn't trying to merge the `subtree add` changes.
cc `@calebcartwright`
Clarify documentation of slice sorting methods
After reading about [this](https://polkadot.network/a-polkadot-postmortem-24-05-2021/), I realized that although the documentation of these methods is not ambiguous in its current state, it is very easy to read it and erroneously assume that their exact behaviour can be relied upon to be deterministic. Although the docs make no guarantees about which index is returned when there are multiple matches, being more explicit about when and how their determinism can be relied upon should help prevent people from making this mistake in the future.
r? ``@steveklabnik``
Update the documentation of `-C force-unwind-tables` for #83482
`panic=unwind` does not require `force-unwind-tables` to be "yes" anymore.
I forgot to update this in #83482.
String::remove_matches O(n^2) -> O(n)
Copy only non-matching bytes. Replace collection of matches into a
vector with iteration over rejections, exploiting the guarantee that we
mutate parts of the haystack that have already been searched over.
r? `@joshtriplett`
Rollup of 6 pull requests
Successful merges:
- #84262 (Fix ICE during type layout when there's a `[type error]`)
- #85973 (Replace a `match` with an `if let`)
- #85996 (rustbuild: take changes to the standard library into account for `download-rustc`)
- #86016 (Unify duplicate linker_and_flavor methods in rustc_codegen_{cranelift,ssa}.)
- #86025 (Remove the install prefix from the rpath set when using -Crpath)
- #86081 (Use `try_into` instead of asserting manually)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove the install prefix from the rpath set when using -Crpath
It was broken anyway for rustup installs and nobody seems to have noticed.
Fixes https://github.com/rust-lang/rust/issues/82392
Unify duplicate linker_and_flavor methods in rustc_codegen_{cranelift,ssa}.
The two methods were exactly the same so this removes the cranelift copy. This will help make sure both they don't get out of sync.
rustbuild: take changes to the standard library into account for `download-rustc`
Previously, changing the standard library with `download-rustc =
"if-unchanged"` would incorrectly reuse the cached compiler and standard
library from CI, which was confusing and led to incorrect test failures
or successes.
r? `@Mark-Simulacrum`
Fix ICE during type layout when there's a `[type error]`
Fixes#84108.
Based on estebank's [comment], except I used `delay_span_bug` because it
should work in more cases, and I think it expresses its intent more
clearly.
r? `@estebank`
[comment]: https://github.com/rust-lang/rust/issues/84108#issuecomment-818916848
Driver improvements
This PR contains a couple of cleanups for the driver and a few small improvements for the custom codegen backend interface. It also implements `--version` and `-Cpasses=list` support for custom codegen backends.
Rollup of 8 pull requests
Successful merges:
- #83433 (Pass --cfg=bootstrap for proc macros built by stage0)
- #84940 (Don't run sanity checks for `x.py setup`)
- #85912 (Use `Iterator::any` and `filter_map` instead of open-coding them)
- #85965 (Remove dead code from `LocalAnalyzer`)
- #86010 (Fix two ICEs in the parser)
- #86040 (Fix display for search results)
- #86058 (Remove `_` from E0121 diagnostic suggestions)
- #86077 (Fix corrected example in E0759.md)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
This patch fixes tests from failing that were matching on `Box<Any>`,
which was the old panic message. Since the new panic message is `Box<dyn
Any>`, the tests have been updated to match against this instead.
Fix corrected example in E0759.md
This pull request fixes#86061, which was probably caused by a copy-paste error, where the supposedly corrected code example was also marked with `compile_fail`. Thus, the fact that the "correct" example actually _isn't_ correct was not caught by the doc-tests. This pull request removes the incorrect `compile_fail` annotation and fixes the example.
r? ``@GuillaumeGomez``
Fix two ICEs in the parser
This pull request fixes#84104 and fixes#84148. The latter is caused by an invalid `assert_ne!()` in the parser, which I have simply removed because the error is then caught in another part of the parser.
#84104 is somewhat more subtle and has to do with a suggestion to remove extraneous `<` characters; for instance:
```rust
fn main() {
foo::<Ty<<<i32>();
}
```
currently leads to
```
error: unmatched angle brackets
--> unmatched-langle.rs:2:10
|
2 | foo::<Ty<<<i32>();
| ^^^ help: remove extra angle brackets
```
which is obviously wrong and stems from the fact that the code for issuing the above suggestion does not consider the possibility that there might be other tokens in between the opening angle brackets. In #84104, this has led to a span being generated that ends in the middle of a multi-byte character (because the code issuing the suggestion thought that it was only skipping over `<`, which are single-byte), causing an ICE.
