Make `nodejs` control the default for RustdocJs tests instead of a hard-off switch
If someone says `x test rustdoc-js-std` explicitly on the command line, it's because they want to run the tests. Give an error instead of doing nothing and reporting success.
Before:
```
; x t rustdoc-js
No nodejs found, skipping "tests/rustdoc-js" tests
Build completed successfully in 0:00:00
```
After:
```
; x t rustdoc-js
thread 'main' panicked at 'need nodejs to run js-doc-test suite', test.rs:1566:13
Build completed unsuccessfully in 0:00:00
```
I recommend viewing the diff with whitespace changes disabled.
r? ````@GuillaumeGomez````
Adjustments for RustyHermit
The interface between `libstd` and the OS changed and some changes are not correctly merged for RustHermit. For instance, the crate `hermit_abi` isn't defined as public, although it provided the socket interface for the application.
In addition, the support of thread::available_parallelism is realized. It returns the number of available processors.
Rollup of 6 pull requests
Successful merges:
- #113536 (avoid building proof trees in select)
- #113558 (Only use max_line_length = 100 for *.rs)
- #113570 (refactor proof tree formatting)
- #113623 (Add jump to doc)
- #113629 (Add Adt to SMIR)
- #113631 (make MCP510 behavior opt-in to avoid conflicts between the CLI and target flavors)
r? `@ghost`
`@rustbot` modify labels: rollup
make MCP510 behavior opt-in to avoid conflicts between the CLI and target flavors
Fixes#113597, which contains more details on how this happens through the code, and showcases an unexpected `Gnu(Cc::Yes, Lld::Yes)` flavor.
#112910 added support to use `lld` when the flavor requests it, but didn't explicitly do so only when using `-Clink-self-contained=+linker` or one of the unstable `-Clinker-flavor`s.
The problem: some targets have a `lld` linker and flavor, e.g. `thumbv6m-none-eabi` from that issue. Users can override the linker but there are no linker flavors precise enough to describe the linker opting out of lld: when using `-Clinker=arm-none-eabi-gcc`, we infer this is a `Cc::Yes` linker flavor, but the `lld` component is unknown and therefore defaulted to the target's linker flavor, `Lld::Yes`.
<details>
<summary>Walkthrough of how this happens</summary>
The linker flavor used is a mix between what can be inferred from the CLI (`-C linker`) and the target's default linker flavor:
- there is no linker flavor on the CLI (and that also offers another workaround on nightly: `-C linker-flavor=gnu-cc -Zunstable-options`), so it will have to be inferred [from here](5dac6b320b/compiler/rustc_codegen_ssa/src/back/link.rs (L1334-L1336)) to [here](5dac6b320b/compiler/rustc_codegen_ssa/src/back/link.rs (L1321-L1327)).
- in [`infer_linker_hints`](5dac6b320b/compiler/rustc_target/src/spec/mod.rs (L320-L352)) `-C linker=arm-none-eabi-gcc` infers a `Some(Cc::Yes)` cc hint, and no hint about lld.
- the target's `linker_flavor` is combined in `with_cli_hints` with these hints. We have our `Cc::Yes`, but there is no hint about lld, [so the target's flavor `lld` component is used](5dac6b320b/compiler/rustc_target/src/spec/mod.rs (L356-L358)). It's [`Gnu(Cc::No, Lld::Yes)`](993deaa0bf/compiler/rustc_target/src/spec/thumb_base.rs (L35)).
- so we now have our `Gnu(Cc::Yes, Lld::Yes)` flavor
</details>
This results in a `Gnu(Cc::Yes, Lld::Yes)` flavor on a non-lld linker, causing an additional unexpected `-fuse-ld=lld` argument to be passed.
I don't know if this target defaulting to `rust-lld` is expected, but until MCP510's new linker flavor are stable, when people will be able to describe their linker/flavor accurately, this PR keeps the stable behavior of not doing anything when the linker/flavor on the CLI unexpectedly conflict with the target's.
I've tested this on a `no_std` `-C linker=arm-none-eabi-gcc -C link-arg=-nostartfiles --target thumbv6m-none-eabi` example, trying to simulate one of `cortex-m`'s test mentioned in issue #113597 (I don't know how to build a local complete `thumbv6m-none-eabi` toolchain to run the exact test), and checked that `-fuse-lld` was indeed gone and the error disappeared.
r? `````@petrochenkov`````
Add jump to doc
I'm using the source code pages of the compiler quite a lot, but one thing missing is the possibility to jump back from the source code to the item documentation. Since I also got a few others complaining about it, I think it's fine to add it since this option is nightly only.
This PR adds a link to jump back to item's documentation on the item definition (so on `Bar` in `struct Bar {... }`, as described in the unofficial [RFC](https://github.com/GuillaumeGomez/rfcs/blob/rustdoc-jump-to-definition/text/000-rustdoc-jump-to-definition.md)).
r? ````@notriddle````
refactor proof tree formatting
mostly:
- handle indentation via a separate formatter
- change nested to use a closure
tested it after rebasing on top of #113536 and everything looks good.
r? `````@BoxyUwU`````
Only use max_line_length = 100 for *.rs
This setting was added to match rustfmt, but it's been taking effect on
all file editing, which I notice most on git `COMMIT_EDITMSG`. I want to
keep my default 72-width commit messages, please. :)
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``
Make Placeholder, GeneratorWitness*, Infer and Error unreachable on SMIR rustc_ty_to_ty
Let's remove these todos to not confuse ``@ericmarkmartin`` if they pick some conversion up.
r? ``@oli-obk``
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``
If someone says `x test rustdoc-js-std` explicitly on the command line, it's because they want to
run the tests. Give an error instead of doing nothing and reporting success.
...which seems not to be available on some platforms.
Or maybe it is under a different name but I don't want to deal with that
Instead, use two u64s. This isn't exactly the same, but we already have
some coverage of the packed u128 case in another test, so it's not
essential to have it here.
Coverage has two FFI functions for computing the hash of a byte string. One
takes a ptr/len pair, and the other takes a NUL-terminated C string.
But on closer inspection, the C string version is unnecessary. The calling-side
code converts a Rust `&str` into a C string, and the C++ code then immediately
turns it back into a ptr/len string before actually hashing it.
The function body immediately treats it as a slice anyway, so this just makes
it possible to call the hash function with arbitrary read-only byte slices.
