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.
Trigger a rebuild when `CLIPPY_CONF_DIR` changes
changelog: none
This is a fix for https://github.com/rust-lang/rust-clippy/issues/9928#issuecomment-1634698183, any time `CLIPPY_CONF_DIR` changes cargo will now rebuild the crate clippy is being run on, giving it a chance to lint with the (potentially) different config file
r? `@flip1995`
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. :)
Add `imports_granularity = "Module"` to rustfmt.toml
This lets rustfmt split/merge imports, `Module` seems to be the most common style in clippy
https://rust-lang.github.io/rustfmt/?version=v1.6.0&search=#imports_granularity
changelog: none
Almost all the updates other than the config file change are from `cargo dev fmt` or blessed tests, the exceptions being
- `tests/ui/single_component_path_imports.rs`
- `tests/ui/single_component_path_imports_nested_first.rs`
- `tests/ui/single_component_path_imports_self_after.rs`
- `tests/ui/single_component_path_imports_self_before.rs`
- `tests/ui/unsafe_removed_from_name.rs` (added a test with merged imports as a drive by)
- `tests/ui/wildcard_imports.rs`
- `tests/ui/wildcard_imports_2021.rs`
[`arithmetic_side_effect`]: allow different types on the right hand side for `Wrapping<T>`
Fixes#11145
This lint has a list of allowed types, one of which is `Wrapping<T>`, but it was only actually allowed if the type on the right hand side was also `Wrapping<T>`, which meant that, for example, `Wrapping<u32> += u32` would still lint. It now allows binary ops involving `Wrapping<T>` regardless of the type on the rhs.
These impls have only existed since Rust 1.60.0, so that is probably why the lint was previously not handling this correctly
changelog: [`arithmetic_side_effect`]: allow different types on the right hand side for `Wrapping<T>` (e.g. `Wrapping<T> += T`)
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``
Default to stable toolchain for metrics workflow
Metrics CI is failing because of a function that was stabilized in 1.70. So for some reason, it's trying to use an older toolchain i seems though I don't understand why it randomly started complaining about that.
Make fields of mir::Terminator public
When trying to use the RA crate, I am unable to access the fields in `hir_def::mir::Terminator`.
I don't see any reason, why these should be private, especially as the fields of `hir_def::mir::Statement` are `pub`.
I am not sure if the fields in `hir_def::mir::SwitchTargets` should be made `pub` too, but at least they are read-accessible via some public methods..
Sorry if I missed something, this is my first PR.
