Fix bootstrap.py uname error
The x.py script fails with `ValueError: too many values to unpack (expected 3)` when uname -smp gives more than 3 words
The error I got:
```
❯ ./x check
Traceback (most recent call last):
File "/data1/edgar/rust/x.py", line 50, in <module>
bootstrap.main()
File "/data1/edgar/rust/src/bootstrap/bootstrap.py", line 1113, in main
bootstrap(args)
File "/data1/edgar/rust/src/bootstrap/bootstrap.py", line 1070, in bootstrap
build = RustBuild(config_toml, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data1/edgar/rust/src/bootstrap/bootstrap.py", line 505, in __init__
self.build = args.build or self.build_triple()
^^^^^^^^^^^^^^^^^^^
File "/data1/edgar/rust/src/bootstrap/bootstrap.py", line 976, in build_triple
return config or default_build_triple(self.verbose)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data1/edgar/rust/src/bootstrap/bootstrap.py", line 259, in default_build_triple
kernel, cputype, processor = uname.decode(default_encoding).split()
^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: too many values to unpack (expected 3)
```
This is because
```
❯ uname -smp
Linux x86_64 AMD Ryzen 7 5800X 8-Core Processor
```
Returns more than 3 space separated words.
Allow to have `-` in rustdoc-json test file name
I extracted this commit from https://github.com/rust-lang/rust/pull/113574.
When I added the test, it kept saying that the JSON file couldn't be found. After investigating for a while, I discovered that we were expecting files to always use `_`, which is quite bad. So I added support for `-` in file names.
r? ``@notriddle``
Test simd-wide-sum for codegen error
This adds the necessary test infrastructure to "build-pass" codegen tests, for the purpose of doing that for a single revision of a codegen test. When mir-opts are tested, the output may vary from the usual, and maybe for positive reasons... but we don't necessarily want to output such bad LLVMIR that LLVM starts crashing on it.
Currently when enabling MIR opts at higher levels this LLVMIR is still emitted, but it was previously disabled for getting in mir-opt's way and as this new revision without `// [mir-opt3]build-pass` would make it more likely to, I would like to not see the testing for the actual results regress again just because it was bundled with an ICE check as well.
This fixes https://github.com/rust-lang/rust/issues/98016
Update cargo
10 commits in 45782b6b8afd1da042d45c2daeec9c0744f72cc7..694a579566a9a1482b20aff8a68f0e4edd99bd28
2023-07-05 16:54:51 +0000 to 2023-07-11 22:28:29 +0000
- fix(embedded): Always generate valid package names (rust-lang/cargo#12349)
- fix(embedded): Error on unsupported commands (rust-lang/cargo#12350)
- chore(ci): Automatically test new packages by using `--workspace` (rust-lang/cargo#12342)
- contrib docs: Add some more detail about how publishing works (rust-lang/cargo#12344)
- docs: Put cargo-add change under nightly (rust-lang/cargo#12343)
- Minor: Use "number" instead of "digit" when explaining Cargo's use of semver (rust-lang/cargo#12340)
- Update criterion (rust-lang/cargo#12338)
- Add profile strip to config docs. (rust-lang/cargo#12337)
- update re: multiple versions that differ only in the metadata tag (rust-lang/cargo#12335)
- doc: state `PackageId`/`SourceId` string is opaque (rust-lang/cargo#12313)
r? ``@ghost``
Implement selection for `Unsize` for better coercion behavior
In order for much of coercion to succeed, we need to be able to deal with partial ambiguity of `Unsize` traits during selection. However, I pessimistically implemented selection in the new trait solver to just bail out with ambiguity if it was a built-in impl:
9227ff28af/compiler/rustc_trait_selection/src/solve/eval_ctxt/select.rs (L126)
This implements a proper "rematch" procedure for dealing with built-in `Unsize` goals, so that even if the goal is ambiguous, we are able to get nested obligations which are used in the coercion selection-like loop:
9227ff28af/compiler/rustc_hir_typeck/src/coercion.rs (L702)
Second commit just moves a `resolve_vars_if_possible` call to fix a bug where we weren't detecting a trait upcasting to occur.
r? ``@lcnr``
Ignore flaky clippy tests.
These tests are frequently failing due to an issue in ui_test. ui_test doesn't appear to have a blanket ignore instruction that I could find, so I just approximated it with ignoring both 32 and 64 bit.
Fixes#113585
(re-)tighten sourceinfo span of adjustments in MIR
Diagnostics rely on the spans of MIR statements being (approximately) correct in order to give suggestions relative to that span (i.e. `shrink_to_hi` and `shrink_to_lo`).
I discovered that we're *intentionally* lowering THIR exprs with their parent expr's span if they come from adjustments that are due to a parent expression. While I understand why that may be desirable to demonstrate the relationship of an adjustment and the expression that requires it, it leads to
1. very verbose borrowck output
2. incorrect spans for suggestions
Some diagnostics get around that by giving suggestions relative to other spans we've collected during MIR lowering, such as the span of the method's identifier (e.g. `name` in `.name()`), but this doesn't work too well when things come from desugaring.
I assume it also has lead to numerous tweaks and complications to diagnostics code down the road, which this PR doesn't necessarily aim to fix but may open the gates to fixing later... The last three commits are simplifications due to the fact that we can assume that the move span actually points to what is being moved (and a test).
This regressed in #89110, which was debated somewhat in #90286. cc `@Aaron1011` who originally made this change.
r? diagnostics
Fixes#113547Fixes#111016
miri: protect Move() function arguments during the call
This gives `Move` operands a meaning specific to function calls:
- for the duration of the call, the place the operand comes from is protected, making all read and write accesses insta-UB.
- the contents of that place are reset to `Uninit`, so looking at them again after the function returns, we cannot observe their contents
Turns out we can replace the existing "retag return place" hack with the exact same sort of protection on the return place, which is nicely symmetric.
Fixes https://github.com/rust-lang/rust/issues/112564
Fixes https://github.com/rust-lang/miri/issues/2927
This starts with a Miri rustc-push, since we'd otherwise conflict with a PR that recently landed in Miri.
(The "miri tree borrows" commit is an unrelated cleanup I noticed while doing the PR. I can remove it if you prefer.)
r? `@oli-obk`
style-guide: Fix chain example to match rustfmt behavior
The style guide gave an example of breaking a multi-line chain element
and all subsequent elements to a new line, but that same example and the
accompanying text also had several chain items stacked on the first
line. rustfmt doesn't do this, except when the rule saying to combine
```
shrt
.y()
```
into
```
shrt.y()
```
applies.
This is a bugfix to match rustfmt behavior, so it's not a breaking change, and
it just needs a ``@rust-lang/style`` reviewer to r+.
This was not the correct fix. The problem was two-fold:
- `download-rustc` didn't respect `llvm.assertions`
- `rust-dev` was missing a bump to `download-ci-llvm-stamp`
The first is fixed in this PR and the latter was fixed a while ago. Revert this change to avoid breaking `rpath = false`.
Uplift `clippy::fn_null_check` lint
This PR aims at uplifting the `clippy::fn_null_check` lint into rustc.
## `incorrect_fn_null_checks`
(warn-by-default)
The `incorrect_fn_null_checks` lint checks for expression that checks if a function pointer is null.
### Example
```rust
let fn_ptr: fn() = /* somehow obtained nullable function pointer */
if (fn_ptr as *const ()).is_null() { /* ... */ }
```
### Explanation
Function pointers are assumed to be non-null, checking for their nullity is incorrect.
-----
Mostly followed the instructions for uplifting a clippy lint described here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751
`@rustbot` label: +I-lang-nominated
r? compiler
Don't use serde-derive in the rls shim
The already-small RLS shim can get a little smaller, and faster to
build, if we drop the serde-derive dependency and decode the one
"method" field it needs manually from `serde_json::Value`.
style-guide: Expand example of combinable expressions to include arrays
Arrays are allowed as combinable expressions, but none of the examples
show that.
CI: use `macos-13` runner for Apple jobs
Trying if performance of Apple CI improves with macOS 13 and SIP disabled. Speed-up:
```
x86_64-apple-1: ~2h 20m > ~1h 20m
x86_64-apple-2: ~1h 45m > ~1h 15m
```
r? `@pietroalbini`
The already-small RLS shim can get a little smaller, and faster to
build, if we drop the serde-derive dependency and decode the one
"method" field it needs manually from `serde_json::Value`.
Replace RPITIT current impl with new strategy that lowers as a GAT
This PR replaces the current implementation of RPITITs with the new implementation that we had under -Zlower-impl-trait-in-trait-to-assoc-ty flag that lowers the RPIT as a GAT on the trait and on the impls that implement that trait.
Opening this PR as a draft because this goes after #112682, ~#112981~ and ~#112983~.
As soon as those are merged, I can rebase and we should run perf, crater and test a lot.
r? `@compiler-errors`
move pal cfgs in f32 and f64 to sys
I'd like to push forward on `sys` being a separate crate. To start with, most of these PAL exception cases are very simple little bits of code like this, so I thought I would try tidying them up.
Copy stage0 `rustc` binaries to `stage0-sysroot`
This is basically a revival of https://github.com/rust-lang/rust/pull/101711 and https://github.com/rust-lang/rust/pull/107956, with an added check that the full sysroot will only be created if the original rustc comes from `stage0/bin`.
What is/should be tested:
- [x] `rustup toolchain link stage0` (new libstd is used correctly)
- [x] `python3 x.py fmt dist --stage 0`
- [x] Custom rustc/cargo in `config.toml` (in this case this logic is ignored)
- [x] Perfbot (try perf run has succeeded)
- [x] Real use case (https://github.com/rust-lang/backtrace-rs/pull/542)
(Hopefully) fixes: https://github.com/rust-lang/rust/issues/101691
This is not the "end all, be all" solution to this problem, but as long as it resolves the basic use-case, and doesn't break perfbot, I say ship it. This code will probably be nuked anyway Soon™ because of the stage redesign.
