Add support for the m68k architecture in 'object_architecture'
This is a tiny PR that adds the m68k architecture to `object_architecture`. This allows us to build rmeta files for that ISA(we use the object crate to pack metadata into object files).
Update wasi-sdk to 27.0 in CI
This updates the wasi-sdk used in CI to build release binaries and run CI with. No major motivation beyond keeping things up-to-date and following the development of wasi-sdk.
Enable T-compiler backport nomination
This patches the triagebot.toml so that it will trigger a backport label on pull requests fixing regressions. Applying a backport label will trigger creating a Zulip thread. For now the configuration only for `T-compiler` labeled regressions.
Comments in the code explain how it works. Documentation [on the forge](https://forge.rust-lang.org/triagebot/backport.html).
```
[backport.foo]
# The pull request MUST have one of these labels
required_pr_labels = ["T-compiler"]
# The regression MUST have this label
required_issue_label = "regression-from-stable-to-beta"
# if the above conditions matches, the PR will receive these labels
add_labels = ["beta-nominated"]
```
Anything to think about before merging this?
thanks for a review
Fix Ord, Eq and Hash implementation of panic::Location
Fixes https://github.com/rust-lang/rust/issues/144486.
Now properly compares/hashes the filename rather than the pointer to the string.
tests: Test line number in debuginfo for diverging function calls
Closesrust-lang/rust#59558 which just [E-needs-test](https://github.com/rust-lang/rust/issues/59558#issuecomment-1322236891).
The bug seems to have been fixed in **nightly-2021-05-10**:
```sh
for toolchain in nightly-2021-05-09 \
nightly-2021-05-10 \
1.88; do
echo -e "\nWith $toolchain:"
rustc +$toolchain tests/codegen/diverging-function-call-debuginfo.rs --emit llvm-ir -o /tmp/out.ll -g -Clto -Copt-level=0
build/x86_64-unknown-linux-gnu/ci-llvm/bin/FileCheck --input-file /tmp/out.ll tests/codegen/diverging-function-call-debuginfo.rs --check-prefix=CHECK --dump-input-context 10 2>/dev/null && echo OK || echo FAIL
done
```
```
With nightly-2021-05-09:
FAIL
With nightly-2021-05-10:
OK
With 1.88:
OK
```
which gives the following list of candidate commits. Not clear which one it is exactly but it doesn't matter much since we can confirm that the test works. I have confirmed locally that with **nightly-2021-05-09** we get `line: 0` for the last call.
<details>
<summary>click to expand</summary>
```
$ git log ^881c1ac408ca82264ec7 --no-merges --oneline
```
f25aa5767f Remove unused `opt_span_warn` function
ebbc949575 Note why `Handler::fatal` is different from `Sesssion::fatal`
96509b4835 Make `Diagnostic::span_fatal` unconditionally raise an error
e49f4471aa Remove some unnecessary uses of `struct_span_fatal`
955fdaea4a Rename `Parser::span_fatal_err` -> `Parser::span_err`
4b7c8b0b53 Add `#[track_caller]` to `FakeDefId::expect_real()`
ba13225ba1 Remove `FakeDefId::expect_local()`
020d83d9f5 Enable `-W semicolon_in_expressions_from_macros` in bootstrap
1b928ff8f8 Update LLVM submodule
c2b15a6b64 Support -C passes in NewPM
5519cbfe33 Don't force -O1 with ThinLTO
7c4989ab70 Drop -opt-bisect-limit=0 flag from test
db140de8f2 Explicitly register GCOV profiling pass as well
5ecbe7fcf8 Explicitly register instrprof pass
0318883cd6 Make -Z new-llvm-pass-manager an Option<bool>
0367e24f94 Avoid predecessors having Drop impls
</details>
This updates the wasi-sdk used in CI to build release binaries and run
CI with. No major motivation beyond keeping things up-to-date and
following the development of wasi-sdk.
Fix typo in `DropGuard` doc
Follows-up rust-lang/rust#144236 (I happened to see the typo yesterday but didn’t think it should delay the PR’s merge so I kept quiet, sorryyyyy).
expand: Micro-optimize prelude injection
Use `splice` to avoid shifting the other items twice.
Put `extern crate std;` first so it's already resolved when we resolve `::std::prelude::rust_20XX`.
coverage: Treat `#[automatically_derived]` as `#[coverage(off)]`
One of the contributing factors behind https://github.com/rust-lang/rust/issues/141577#issuecomment-3120667286 was the presence of derive-macro-generated code containing nested closures.
Coverage instrumentation already has a heuristic for skipping code marked with `#[automatically_derived]` (rust-lang/rust#120185), because derived code is usually not worth instrumenting, and also has a tendency to trigger vexing edge-case bugs in coverage instrumentation or coverage codegen.
However, the existing heuristic only applied to the associated items directly within an auto-derived impl block, and had no effect on closures or nested items within those associated items.
This PR therefore extends the search for `#[coverage(..)]` attributes to also treat `#[automatically_derived]` as an implied `#[coverage(off)]` for the purposes of coverage instrumentation.
---
This change doesn’t rule out an entire category of bugs, because it only affects code that actually uses the auto-derived attribute. But it should reduce the overall chance of edge-case macro span bugs being observed in the wild.
Add a test case for the issue #129882
It ensures that using the `generic_const_exprs` feature in a library crate without enabling it in a dependent crate does not lead to an ICE.
Closes https://github.com/rust-lang/rust/issues/129882.
feat: Right align line numbers
As part of my work on getting `annotate-snipptes` to be used as `rustc`'s renderer, I realized that `rustc` left-aligned line numbers, while `annotate-snippets` right-aligned them. This PR switches `rustc` to right-align the line numbers, matching `annotate-snippets`. In practice, this change isn't very noticeable in day-to-day output, as it only shows up when a diagnostic span contains line numbers with different lengths (9->10, 99->100, 999->1000, etc.).
`rustc`
```
error[E0412]: cannot find type `F` in this scope
--> $DIR/ui-testing-optout.rs:92:10
|
4 | type A = B;
| ----------- similarly named type alias `A` defined here
...
92 | type E = F;
| ^ help: a type alias with a similar name exists: `A`
```
`annotate-snippets`
```
error[E0412]: cannot find type `F` in this scope
--> $DIR/ui-testing-optout.rs:92:10
|
4 | type A = B;
| ----------- similarly named type alias `A` defined here
...
92 | type E = F;
| ^ help: a type alias with a similar name exists: `A`
```
r? ``@compiler-errors``
Ensure external paths passed via flags end up in rustdoc depinfo
rustdoc has many flags to pass external HTML/Markdown/CSS files that end up in the build. These need to be recorded in depinfo so that Cargo will rebuild the crate if they change.
bootstrap: enable tidy auto extra checks on tools profile
alternative to https://github.com/rust-lang/rust/pull/144461
this won't affect CI or any `./configure` based workflows, and will also not affect every rust contributor like that PR will. a slower rollout of this feature should reduce disruption if issues are discovered with it.
r? ``@Kobzol``
tidy: increase performance of auto extra checks feature
Removes the repeated calls to git diff.
Halves the overhead of the tidy extra checks feature from 0.1 seconds to 0.05 on my machine, but probably will be more significant on systems on slow disks or less memory for i/o cache.
r? ``@Kobzol``
thread name in stack overflow message
Fixesrust-lang/rust#144481, which is caused by the thread name not being initialised yet when setting up the stack overflow information. Unfortunately, the stack overflow UI test did not test for the correct thread name being present, and testing this separately didn't occur to me when writing https://github.com/rust-lang/rust/pull/140628.
This PR contains the smallest possible fix I could think of: passing the thread name explicitly to the platform thread creation function. In the future I'd very much like to explore some possibilities around merging the thread packet and thread handle into one structure and using that in the platform code instead – but that's best left for another PR.
This PR also amends the stack overflow test to check for thread names, so we don't run into this again.
``@rustbot`` label +beta-nominated
Add explicit download methods to download module in bootstrap
This PR attempts to decouple the default initialization of the config object from parse_inner. It moves specific download methods, previously used during the initial config setup, into standalone functions outside the config implementation.
r? ``@Kobzol``
fix(debuginfo): disable overflow check for recursive non-enum types
Commit b10edb4 introduce an overflow check when generating debuginfo for expanding recursive types. While this check works correctly for enums, it can incorrectly prune valid debug information for structures.
For example see rust-lang/rust#143241 (https://github.com/rust-lang/rust/issues/143241#issuecomment-3073721477). Furthermore, for structures such check does not make sense, since structures with recursively expanding types simply will not compile (there is a `hir_analysis_recursive_generic_parameter` for that).
closesrust-lang/rust#143241
Document why `Range*<&T> as RangeBounds<T>` impls are not `T: ?Sized`, and give an alternative.
`Range*<&T> as RangeBounds<T>` impls have been tried to be relaxed to `T: ?Sized` at least twice:
* https://github.com/rust-lang/rust/pull/61584
* https://github.com/rust-lang/rust/pull/64327
I also was just about to make another PR to do it again until I `./x.py test library/alloc` and rediscovered the type inference regression, then searched around and found the previous PRs. Hence this PR instead so hopefully that doesn't keep happening 😛.
These impls cannot be relaxed for two reasons:
1. Type inference regressions: See ``@SimonSapin's`` explanation from a previous PR: https://github.com/rust-lang/rust/pull/61584#issuecomment-499601046
2. It's a breaking change: `impl RangeBounds<MyUnsizedType> for std::ops::Range<&MyUnsizedType>` is allowed after the coherence rebalance ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=f704a6fe53bfc33e55b2fc246d895ec2)), and relaxing these impls would conflict with that downstream impl.
This PR adds doc-comments explaining that not having `T: ?Sized` is intentional[^1], and gives an explicit alternative: `(Bound<&T>, Bound<&T>)`.
Technically, the impls for the unstable new `std::range` types could be relaxed, as they are still unstable so the change would not be breaking, but having them be different in this regard seems worse (and the non-iterable `RangeTo/RangeToInclusive` range types are shared between the "new" and "old" so cannot be changed anyway), and then the type inference regression would pop up in whatever edition the new range types stabilize in.
The "see \<link\> for discussion of those issues" is intentionally left as a non-doc comment just for whoever may try to relax these impls again in the future, but if it is preferred to have the link in the docs I can add that.
Closes https://github.com/rust-lang/rust/issues/107196 (as wontfix)
CC https://github.com/rust-lang/rust/issues/64027
[^1]: "intentional" is maybe a bit of strong wording, should it instead say something like "was stabilized without it and it would be breaking to change it now"?
Implementation: `#[feature(sync_nonpoison)]`, `#[feature(nonpoison_mutex)]`
Continuation of https://github.com/rust-lang/rust/pull/134663
Tracking Issue: https://github.com/rust-lang/rust/issues/134645
This PR implements a new `sync/nonpoison` module, as well as the `nonpoison` variant of the `Mutex` lock.
There are 2 main changes here, the first is the new `nonpoison::mutex` module, and the second is the `mutex` integration tests.
For the `nonpoison::mutex` module, I did my best to align it with the current state of the `poison::mutex` module. This means that several unstable features (`mapped_lock_guards`, `lock_value_accessors`, and `mutex_data_ptr`) are also in the new `nonpoison::mutex` module, under their respective feature gates. Everything else in that file is under the correct feature gate (`#[unstable(feature = "nonpoison_mutex", issue = "134645")]`).
Everything in the `nonpoison::mutex` file is essentially identical in spirit, as we are simply removing the error case from the original `poison::mutex`.
The second big change is in the integration tests. I created a macro called that allows us to duplicate tests that are "generic" over the different mutex types, in that the poison mutex is always `unwrap`ped.
~~I think that there is an argument against doing this, as it can make the tests a bit harder to understand (and language server capabilities are weaker within macros), but I think the benefit of code deduplication here is worth it. Note that it is definitely possible to generalize this (with a few tweaks) to testing the other `nonpoison` locks when they eventually get implemented, but I'll leave that for a later discussion.~~
