| Age | Commit message (Collapse) | Author | Lines |
|---|
|
...to both compiler contributors and other rustc invokers.
The previous error messaging was extremely unfriendly,
and potentially both confusing and alarming.
The entire modules is extracted into a new file to help
ease of reading, and plenty of comments get layered in.
The design of the messaging is focused on preventing
the overall purpose of the output from being too opaque
in common cases, so users understand why it is there.
There's not an immediate need for it being actionable,
but some suggestions are offered anyways.
|
|
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](https://github.com/lqd/rust/blob/5dac6b320be868f898a3c753934eabc79ff2e406/compiler/rustc_codegen_ssa/src/back/link.rs#L1334-L1336) to [here](https://github.com/lqd/rust/blob/5dac6b320be868f898a3c753934eabc79ff2e406/compiler/rustc_codegen_ssa/src/back/link.rs#L1321-L1327).
- in [`infer_linker_hints`](https://github.com/lqd/rust/blob/5dac6b320be868f898a3c753934eabc79ff2e406/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](https://github.com/lqd/rust/blob/5dac6b320be868f898a3c753934eabc79ff2e406/compiler/rustc_target/src/spec/mod.rs#L356-L358). It's [`Gnu(Cc::No, Lld::Yes)`](https://github.com/rust-lang/rust/blob/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/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 Adt to SMIR
r? ````@oli-obk````
|
|
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. :)
|
|
avoid building proof trees in select
otherwise we ICE because select isn't currently set up to print proof trees.
r? `````@BoxyUwU`````
|
|
Bump bootstrap to 1.72 beta
|
|
Rollup of 7 pull requests
Successful merges:
- #113353 (Implement selection for `Unsize` for better coercion behavior)
- #113553 (Make Placeholder, GeneratorWitness*, Infer and Error unreachable on SMIR rustc_ty_to_ty)
- #113598 (Update cargo)
- #113603 (Test simd-wide-sum for codegen error)
- #113613 (Allow to have `-` in rustdoc-json test file name)
- #113615 (llvm-wrapper: adapt for LLVM API change)
- #113616 (Fix bootstrap.py uname error)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
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.
|
|
llvm-wrapper: adapt for LLVM API change
Adapts the wrapper for LLVM commit https://github.com/llvm/llvm-project/commit/546ec641b4b1bbbf9e66a53983b635fe85d365e6.
Found by the experimental rust + LLVM @ HEAD bot: https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/20723#01894922-ed5d-4830-81f6-a27fb82ec8c7/210-645
|
|
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:
https://github.com/rust-lang/rust/blob/9227ff28aff55b252314076fcf21c9a66f10ac1e/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:
https://github.com/rust-lang/rust/blob/9227ff28aff55b252314076fcf21c9a66f10ac1e/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``
|
|
|
|
|
|
|
|
|
|
|
|
|
|
because sometimes users can't opt out
|
|
|
|
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
|
|
|
|
|
|
|
|
Don't fail early if `try_run` returns an error
Fixes https://github.com/rust-lang/rust/issues/113208.
Follow-up of #112962.
r? `@jyn514`
|
|
r=oli-obk
(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 #113547
Fixes #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`
|
|
|
|
The x.py script fails with `ValueError: too many values to unpack (expected 3)` when uname -smp gives more than 3 words
|
|
Adapts the wrapper for LLVM commit
https://github.com/llvm/llvm-project/commit/546ec641b4b1bbbf9e66a53983b635fe85d365e6.
Found by the experimental rust + LLVM @ HEAD bot: https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/20723#01894922-ed5d-4830-81f6-a27fb82ec8c7/210-645
|
|
|
|
remove unnecessary `Rc`
the typeck results are already in a `RefCell`, so we don't need to wrap its fields in an `Rc`
|
|
Rollup of 5 pull requests
Successful merges:
- #113373 (various download-rustc fixes)
- #113385 (style-guide: Fix chain example to match rustfmt behavior)
- #113567 (While let suggestion will work for closure body)
- #113579 (Revert "fix: :bug: etc/bash_complettion -> src/etc/... to avoid copy …)
- #113595 (Use constants from object crate)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Use constants from object crate
Replace hard-coded values with `GNU_PROPERTY_{X86|AARCH64}_FEATURE_1_AND` from the object crate.
When working on [issue](https://github.com/rust-lang/rust/issues/103001) it was suggested that we moved these constants to the object crate . [PR](https://github.com/gimli-rs/object/pull/537). Now that that the object crate has been updated [PR](https://github.com/rust-lang/rust/pull/111413) we can make this change.
|
|
Revert "fix: :bug: etc/bash_complettion -> src/etc/... to avoid copy …
## why
- [x] revert my broken PR
https://github.com/rust-lang/rust/pull/110906
This reverts commit 08ce68b6a6bad360e9c3611ad60cf6598401f878.
|
|
While let suggestion will work for closure body
Fixes #113354
|
|
r=calebcartwright
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+.
|
|
various download-rustc fixes
separated out from https://github.com/rust-lang/rust/pull/112143 because it keeps getting stuck in limbo.
best reviewed commit-by-commit
|
|
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`.
|
|
Not only are they a pain to update, but they differ depending on whether `parallel-rustc` is enabled or not
|
|
|
|
|
|
|
