bors [Wed, 17 Aug 2022 14:49:05 +0000 (14:49 +0000)]
Auto merge of #100677 - matthiaskrgr:rollup-au41ho1, r=matthiaskrgr
Rollup of 15 pull requests
Successful merges:
- #99474 (Rustdoc json tests: New `@hasexact` test command)
- #99972 (interpret: only consider 1-ZST when searching for receiver)
- #100018 (Clean up `LitKind`)
- #100379 (triagebot: add translation-related mention groups)
- #100389 (Do not report cycle error when inferring return type for suggestion)
- #100489 (`is_knowable` use `Result` instead of `Option`)
- #100532 (unwind: don't build dependency when building for Miri)
- #100608 (needless separation of impl blocks)
- #100621 (Pass +atomics-32 feature for {arm,thumb}v4t-none-eabi)
- #100646 (Migrate emoji identifier diagnostics to `SessionDiagnostic` in rustc_interface)
- #100652 (Remove deferred sized checks (make them eager))
- #100655 (Update books)
- #100656 (Update cargo)
- #100660 (Fixed a few documentation errors)
- #100661 (Fixed a few documentation errors)
Matthias Krüger [Wed, 17 Aug 2022 10:33:00 +0000 (12:33 +0200)]
Rollup merge of #100656 - ehuss:update-cargo, r=ehuss
Update cargo
3 commits in efd4ca3dc0b89929dc8c5f5c023d25978d76cb61..9809f8ff33c2b998919fd0432c626f0f7323697a
2022-08-12 01:28:28 +0000 to 2022-08-16 22:10:06 +0000
- Improve error message for an array value in the manifest (rust-lang/cargo#10944)
- Fix file locking being not supported on Android raising an error (rust-lang/cargo#10975)
- Bump to 0.66.0, update changelog (rust-lang/cargo#10983)
5 commits in f3d3953bf3b158d596c96d55ce5366f9f3f972e9..e647eb102890e8927f488bea12672b079eff8d9d
2022-08-01 17:17:37 -0700 to 2022-08-16 11:35:27 -0700
- #[non_exhaustive] on variant blocks cross-crate as casts (rust-lang/reference#1249)
- Revert let chains reference docs (rust-lang/reference#1251)
- Update subtyping.md (rust-lang/reference#1240)
- a fix about .await (rust-lang/reference#1245)
- Be less specific about the representation of `+bundle` (rust-lang/reference#1246)
8 commits in ee342dc91e1ba1bb1e1f1318f84bbe3bfac04798..03301f8ae55fa6f20f7ea152a517598e6db2cdb7
2022-07-27 11:06:36 -0300 to 2022-08-14 08:51:44 -0300
- Update print.md (rust-lang/rust-by-example#1597)
- in Meta, replace 'playpen' with 'playground' (rust-lang/rust-by-example#1596)
- Update doc comment to link to name field without compilation warning (rust-lang/rust-by-example#1595)
- add line numbers for playpen fixes rust-lang/rust-by-example#1593 (rust-lang/rust-by-example#1594)
- clarify that the map-reduce example relies on static data (rust-lang/rust-by-example#1592)
- Update flow_control.md (rust-lang/rust-by-example#1591)
- Remove duplicate line in the hello/print.md file (rust-lang/rust-by-example#1590)
- Make rust editable in chapter on defaults (rust-lang/rust-by-example#1589)
## rustc-dev-guide
15 commits in 04f3cf0bb2f5a6ee2bfc4b1a6a6cd8c11d1c5531..d3daa1f28e169087becbc5e2b49ac91ca0405a44
2022-07-31 07:46:57 +0200 to 2022-08-13 10:00:38 +0900
- Improve the "Diagnostic items" chapter (rust-lang/rustc-dev-guide#1427)
- date-check: crates-io
- fix/improve compiler-debugging
- Update src/compiler-debugging.md
- add gdb tips for symbol-mangling-version
- move references down to avoid clutter (rust-lang/rustc-dev-guide#1420)
- update date-check format on github issue (rust-lang/rustc-dev-guide#1416)
- Fix legend colors in dark mode
- Add color for downloaded nodes
- Add colors to diagram
- Add bootstrapping diagram
- date-check: rustc_codegen_ssa is still alive
- note is now too old to be relevant
- date-check: be more strict
- make date-check more lightweight (rust-lang/rustc-dev-guide#1394)
## edition-guide
3 commits in c55611dd6c58bdeb52423b5c52fd0f3c93615ba8..6038be9d37d7251c966b486154af621d1794d7af
2022-02-21 14:21:39 +0100 to 2022-08-15 08:12:42 -0700
- use title "The Rust Edition Guide" everywhere (rust-lang/edition-guide#280)
- "Creating a new project": add example using 'cargo new --edition YEAR' (rust-lang/edition-guide#279)
- fixes rust-lang/edition-guide#277: mention rust 1.0 release month and year (rust-lang/edition-guide#278)
Matthias Krüger [Wed, 17 Aug 2022 10:32:57 +0000 (12:32 +0200)]
Rollup merge of #100652 - compiler-errors:no-defer-sized-checks, r=TaKO8Ki
Remove deferred sized checks (make them eager)
Improves diagnostics spans... this doesn't seem to be the case anymore:
```rust
// Some additional `Sized` obligations badly affect type inference.
// These obligations are added in a later stage of typeck.
pub(super) deferred_sized_obligations:
RefCell<Vec<(Ty<'tcx>, Span, traits::ObligationCauseCode<'tcx>)>>,
```
Matthias Krüger [Wed, 17 Aug 2022 10:32:55 +0000 (12:32 +0200)]
Rollup merge of #100621 - taiki-e:armv4t-atomics-32, r=cuviper
Pass +atomics-32 feature for {arm,thumb}v4t-none-eabi
Similar to https://github.com/rust-lang/rust/commit/89582e8193e0da64a54c4ffae7f9fa64ed9fe2af, but for ARMv4t.
Pre-v6 ARM target does not have atomic CAS, except for Linux and Android where atomic CAS is provided by compiler-builtins. So, there is a similar issue as thumbv6m.
I have confirmed that enabling the `atomics-32` target feature fixes the problem in the project affected by this issue. (https://github.com/taiki-e/portable-atomic/pull/28#discussion_r946604136)
Matthias Krüger [Wed, 17 Aug 2022 10:32:53 +0000 (12:32 +0200)]
Rollup merge of #100532 - RalfJung:unwind-miri, r=Mark-Simulacrum
unwind: don't build dependency when building for Miri
This is basically re-submitting https://github.com/rust-lang/rust/pull/94813.
In that PR there was a suggestion to instead have bootstrap set a `RUST_CHECK` env var and use that rather than doing something Miri-specific. However, such an env var would mean that when switching between `./x.py check` and `./x.py build`, the build script gets re-run each time, which doesn't seem good. So I think for now checking for Miri probably causes fewer problems.
Matthias Krüger [Wed, 17 Aug 2022 10:32:51 +0000 (12:32 +0200)]
Rollup merge of #100389 - compiler-errors:return-type-suggestion-cycle, r=cjgillot
Do not report cycle error when inferring return type for suggestion
The UI test is a good example of a case where this happens. The cycle is due to needing the value of the return type `-> _` to compute the variances of items in the crate, but then needing the variances of the items in the crate to do typechecking to infer what `-> _`'s real type is.
Since we're already gonna emit an error in astconv, just delay the cycle bug as an error.
Matthias Krüger [Wed, 17 Aug 2022 10:32:50 +0000 (12:32 +0200)]
Rollup merge of #100379 - davidtwco:triagebot-diag, r=Mark-Simulacrum
triagebot: add translation-related mention groups
- Move some code around so that triagebot can ping relevant parties when translation logic is modified.
- Add mention groups to triagebot for translation-related files/folders.
- Auto-label pull requests with changes to translation-related files/folders with `A-translation`.
Matthias Krüger [Wed, 17 Aug 2022 10:32:48 +0000 (12:32 +0200)]
Rollup merge of #99972 - RalfJung:1zst, r=lcnr
interpret: only consider 1-ZST when searching for receiver
`repr(transparent)` currently entirely rejects ZST with alignment larger than 1 (which is odd, arguably [this](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=02870f29396fa948c3123cb53d869ad1) should be accepted), so this should be safe. And if it ever isn't safe then that is very likely a bug elsewhere in the compiler.
Matthias Krüger [Wed, 17 Aug 2022 10:32:47 +0000 (12:32 +0200)]
Rollup merge of #99474 - aDotInTheVoid:rustdoc-json-noinline-test-cleanup, r=CraftSpider
Rustdoc json tests: New @hasexact test command
Alot of the time, we wanted to assert that a module had an exact set of items. Most of the time this was done by asserting that the ```@count``` of the module was `n`, and then doing `n` ```@has``` checks on the module.
This was tedious, so often shortcuts were done.
This PR adds a new command to jsondocck to allow consistently expressing this behavior, and then uses it to clean up the tests.
Takayuki Maeda [Tue, 16 Aug 2022 20:08:04 +0000 (05:08 +0900)]
Rollup merge of #100629 - GuillaumeGomez:merged-ty, r=compiler-errors
Use `merged_ty` method instead of rewriting it every time
`merged_ty` [source code](https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_typeck/check/coercion.rs.html#1331-1333) is quite literally the same, so instead of rewriting it, makes more sense to use the method instead.
Takayuki Maeda [Tue, 16 Aug 2022 20:08:03 +0000 (05:08 +0900)]
Rollup merge of #100625 - reitermarkus:ip-display-buffer, r=thomcc
Add `IpDisplayBuffer` helper struct.
This removes the dependency on `std::io::Write` for implementing `Display`, allowing it to be moved to `core` as proposed in https://github.com/rust-lang/rfcs/pull/2832.
Dylan DPC [Tue, 16 Aug 2022 12:46:11 +0000 (18:16 +0530)]
Rollup merge of #99942 - compiler-errors:nonsense-un-tupled-fn-trait-error, r=cjgillot
Fix nonsense non-tupled `Fn` trait error
Given this code:
```rust
#![feature(unboxed_closures)]
fn a<F: Fn<usize>>(f: F) {}
fn main() {
a(|_: usize| {});
}
```
We currently emit this error:
```
error[E0631]: type mismatch in closure arguments
--> src/main.rs:6:5
|
6 | a(|_: usize| {});
| ^ ---------- found signature of `fn(usize) -> _`
| |
| expected signature of `fn(usize) -> _`
|
note: required by a bound in `a`
--> src/main.rs:3:9
|
3 | fn a<F: Fn<usize>>(f: F) {}
| ^^^^^^^^^ required by this bound in `a`
For more information about this error, try `rustc --explain E0631`.
error: could not compile `playground` due to previous error
```
Notably, it says the same thing for "expected" and "found"!
Fix the output so that we instead emit:
```
error[E0308]: mismatched types
--> /home/gh-compiler-errors/test.rs:6:5
|
6 | a(|_: usize| {});
| ^ types differ
|
= note: expected trait `Fn<usize>`
found trait `Fn<(usize,)>`
note: required by a bound in `a`
--> /home/gh-compiler-errors/test.rs:3:9
|
3 | fn a<F: Fn<usize>>(f: F) {}
| ^^^^^^^^^ required by this bound in `a`
error: aborting due to previous error
```
The error could still use some work, namely the "mismatched types" part, but I'm leaving it a bit rough since the only way you'd ever get this error is when you're messing with `#![feature(unboxed_closures)]`.
Simply making sure we actually print out the difference in trait-refs is good enough for me. I could probably factor in some additional improvements if those are desired.
bors [Tue, 16 Aug 2022 05:13:38 +0000 (05:13 +0000)]
Auto merge of #100611 - matthiaskrgr:rollup-rxj10ur, r=matthiaskrgr
Rollup of 6 pull requests
Successful merges:
- #100338 (when there are 3 or more return statements in the loop)
- #100384 (Add support for generating unique profraw files by default when using `-C instrument-coverage`)
- #100460 (Update the minimum external LLVM to 13)
- #100567 (Add missing closing quote)
- #100590 (Suggest adding an array length if possible)
- #100600 (Rename Machine memory hooks to suggest when they run)
Matthias Krüger [Tue, 16 Aug 2022 04:06:00 +0000 (06:06 +0200)]
Rollup merge of #100600 - saethlin:rename-memory-hooks, r=RalfJung
Rename Machine memory hooks to suggest when they run
Some of the other memory hooks start with `before_` or `after_` to indicate that they run before or after a certain operation. These don't, so I was a bit confused as to when they are supposed to run.
`memory_read` can be read two ways in English, "memory was read" or "this is a memory read" so without the prefix this was especially ambiguous.
Matthias Krüger [Tue, 16 Aug 2022 04:05:56 +0000 (06:05 +0200)]
Rollup merge of #100384 - ridwanabdillahi:instr_profile_output, r=wesleywiser
Add support for generating unique profraw files by default when using `-C instrument-coverage`
Currently, enabling the rustc flag `-C instrument-coverage` instruments the given crate and by default uses the naming scheme `default.profraw` for any instrumented profile files generated during the execution of a binary linked against this crate. This leads to multiple binaries being executed overwriting one another and causing only the last executable run to contain actual coverage results.
This can be overridden by manually setting the environment variable `LLVM_PROFILE_FILE` to use a unique naming scheme.
This PR adds a change to add support for a reasonable default for rustc to use when enabling coverage instrumentation similar to how the Rust compiler treats generating these same `profraw` files when PGO is enabled.
The new naming scheme is set to `default_%m_%p.profraw` to ensure the uniqueness of each file being generated using [LLVMs special pattern strings](https://clang.llvm.org/docs/SourceBasedCodeCoverage.html#running-the-instrumented-program).
Today the compiler sets the default for PGO `profraw` files to `default_%m.profraw` to ensure a unique file for each run. The same can be done for the instrumented profile files generated via the `-C instrument-coverage` flag as well which LLVM has API support for.
Matthias Krüger [Tue, 16 Aug 2022 04:05:55 +0000 (06:05 +0200)]
Rollup merge of #100338 - lyming2007:issue-100285-fix, r=petrochenkov
when there are 3 or more return statements in the loop
emit the first 3 errors and duplicated diagnostic information
modified: compiler/rustc_typeck/src/check/coercion.rs
new file: src/test/ui/typeck/issue-100285.rs
new file: src/test/ui/typeck/issue-100285.stderr
- Rename `ast::Lit::token` as `ast::Lit::token_lit`, because its type is
`token::Lit`, which is not a token. (This has been confusing me for a
long time.)
reasonable because we have an `ast::token::Lit` inside an `ast::Lit`.
- Rename `LitKind::{from,to}_lit_token` as
`LitKind::{from,to}_token_lit`, to match the above change and
`token::Lit`.
There is some redundancy here, but the extra assertions make it easier
to keep track of relative things, e.g. `ExprKind` is the biggest part
of `Expr`.
bors [Tue, 16 Aug 2022 02:32:47 +0000 (02:32 +0000)]
Auto merge of #100237 - cjgillot:no-special-hash-hir, r=nagisa
Remove manual implementations of HashStable for hir::Expr and hir::Ty.
We do not need to force hashing HIR bodies inside those nodes. The contents of bodies are not accessible from the `hir_owner` query which used `hash_without_bodies`. When the content of a body is required, the access is still done using `hir_owner_nodes`, which continues hashing HIR bodies.
Yiming Lei [Tue, 9 Aug 2022 18:27:04 +0000 (11:27 -0700)]
when there are 3 or more return statements in the loop
emit the first 3 errors and duplicated diagnostic information
using take of iterator for the first third return
modified: compiler/rustc_typeck/src/check/coercion.rs
new file: src/test/ui/typeck/issue-100285.rs
new file: src/test/ui/typeck/issue-100285.stderr
Matthias Krüger [Mon, 15 Aug 2022 18:11:39 +0000 (20:11 +0200)]
Rollup merge of #100568 - ivmarkov:master, r=Mark-Simulacrum
Fix STD build for ESP-IDF
We have accidentally broken the STD build for the Tier 3 `target_os="espidf"` (only) by pushing non-buildable changes to `libc` which ended up in version 0.2.229.
`libc` [was fixed](https://github.com/rust-lang/libc/commit/d0e3ff01a808d429baf925bf0e6e5f2273de1ac0) from V0.2.230 onwards. This PR is only upgrading the `libc` dependency in `Cargo.lock` to latest (V0.2.231).
`Cargo.lock` was modified by using `cargo update -p libc`.
Matthias Krüger [Mon, 15 Aug 2022 18:11:37 +0000 (20:11 +0200)]
Rollup merge of #100528 - tux3:riscv-bitmanip-features, r=davidtwco
Support 1st group of RISC-V Bitmanip backend target features
These target features use the same names as LLVM and `is_riscv_feature_detected!`, they are:
- zba (address generation instructions)
- zbb (basic bit manipulation)
- zbc (carry-less multiplication)
- zbs (single-bit manipulation)
The extension is frozen and ratified, and I don't think we should expect LLVM to change those feature names in the future.
For reference, the specification for the B extension can be found here: https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0-38-g865e7a7.pdf)
On my current project, I see a 7.6% reduction in binary size with these features on, so I have some incentive to try to silence the "unknown feature" warning from `-Ctarget-feature` =)
Matthias Krüger [Mon, 15 Aug 2022 18:11:35 +0000 (20:11 +0200)]
Rollup merge of #100458 - compiler-errors:fn-argument-span, r=estebank
Adjust span of fn argument declaration
Span of a fn argument declaration goes from:
```
fn foo(i : i32 , ...)
^^^^^^^^
```
to:
```
fn foo(i : i32 , ...)
^^^^^^^
```
That is, we don't include the extra spacing up to the trailing comma, which I think is more correct.
cc https://github.com/rust-lang/rust/pull/99646#discussion_r944568074
r? ``@estebank``
---
The two tests that had dramatic changes in their rendering I think actually are improved, though they are kinda poor spans both before and after the changes. :shrug: Thoughts?
Matthias Krüger [Mon, 15 Aug 2022 18:11:34 +0000 (20:11 +0200)]
Rollup merge of #100377 - est31:fluent_grepability, r=davidtwco
Replace - with _ in fluent slugs to improve developer workflows
This is a proposal to smoothen the compiler contribution experience in the face of the move to fluent.
## Context
The fluent project has introduced a layer of abstraction to compiler errors. Previously, people would write down error messages directly in the same file the code was located to emit them. Now, there is a slug that connects the code in the compiler to the error message in the ftl file.
Old:
```Rust
let msg = format!(
"bounds on `{}` are most likely incorrect, consider instead \
using `{}` to detect whether a type can be trivially dropped",
predicate,
cx.tcx.def_path_str(needs_drop)
);
lint.build(&msg).emit();
```
New (Rust side):
```Rust
lint.build(fluent::lint::drop_trait_constraints)
.set_arg("predicate", predicate)
.set_arg("needs_drop", cx.tcx.def_path_str(needs_drop))
.emit();
```
New (Fluent side):
```fluent
lint-drop-trait-constraints =
bounds on `{$predicate}` are most likely incorrect, consider instead using `{$needs_drop}` to detect whether a type can be trivially dropped
```
You will note that in the ftl file, the slug is slightly different from the slug in the Rust file: The ftl slug uses `-` (e.g. `lint-drop-trait-constraints`) while the rust slug uses `::` and `_` (e.g. `lint::drop_trait_constraints`). This choice was probably done due to:
* Rust not accepting `-` in identifiers (as it is an operator)
* fluent not supporting the `:` character in slug names (parse error upon attempts)
* all official fluent documentation using `-` instead of `_`
## The problem
The two different types of slugs, one with `-`, and one with `_`, cause difficulties for contributors. Imagine you don't have perfect knowledge of where stuff is in the compiler (i would say this is most people), and you encounter an error for which you think there is something you could improve that is not just a rewording.
So you want to find out where in the compiler's code that error is being emitted. The best way is via grepping.
1. you grep for the message in the compiler's source code. You discover the ftl file and find out the slug for that error.
2. That slug however contains `-` instead of `_`, so you have to manually translate the `-`'s into `_`s, and furthermore either remove the leading module name, or replace the first `-` with a `::`.
3. you do a second grep to get to the emitting location in the compiler's code.
This translation difficulty in step 2 appears also in the other direction when you want to figure out what some code in the compiler is doing and use error messages to help your understanding. Comments and variable names are way less exposed to users so [are more likely going to lie](https://github.com/rust-lang/rust/commit/cc3c5d2700481bae497d6cde825c1d48e79c776a) than error messages.
I think that at least the `-`→`_` translation which makes up most of step 2 can be removed at low cost.
## The solution
If you look closely, the practice of fluent to use `-` is only a stylistic choice and it is not enforced by fluent implementations, neither the playground nor the one the rust compiler uses, that slugs may not contain `_`. Thus, we can in fact migrate the ftl side to `_`. So now we'll have slugs like `lint_drop_trait_constraints` on the ftl side. You only have to do one replacement now to get to the Rust slug: remove the first `_` and place a `::` in its stead. I would argue that this change is in fact useful as it allows you to control whether you want to look at the rust side of things or the ftl side of things via changing the query string only: with an increased number of translations checked into the repository, grepping for raw slugs will return the slug in many ftl files, so an explicit step to look for the source code is always useful. In the other direction (rust to fluent), you don't need a translation at all any more, as you can just take the final piece of the slug (e.g. `drop_trait_constraints`) and grep for that. The PR also adds enforcement to forbid usage of `_` in slug names. Internal slug names (those leading with a `-`) are exempt from that enforcement.
As another workflow that benefits from this change, people who add new errors don't have to do that `-` conversion either.
| Before/After | Fluent slug | Rust slug (no change) |
|--|--|--|
| Before | `lint-drop-trait-constraints` | `lint::drop_trait_constraints`|
| After | `lint_drop_trait_constraints` | `lint::drop_trait_constraints`|
Note that I've suggested this previously in the translation thread on zulip. I think it's important to think about non-translator contribution impact of fluent. I have certainly plans for more improvements, but this is a good first step.
Matthias Krüger [Mon, 15 Aug 2022 18:11:33 +0000 (20:11 +0200)]
Rollup merge of #100325 - aDotInTheVoid:rdj-import-impl, r=GuillaumeGomez
Rustdoc-Json: Don't remove impls for items imported from private modules
After #99287, items in private modules may still be in the json output, if a public import accesses them. To reflect this, items that are imported need to be marked as retained in the `Stripper` pass, so their impls arn't removed by `ImplStripper`.
[More context on zulip](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/Populating.20cache.2Eimpls), thanks to @ jyn514 for helping debug this.
bors [Mon, 15 Aug 2022 15:25:31 +0000 (15:25 +0000)]
Auto merge of #100569 - matthiaskrgr:rollup-9450lzs, r=matthiaskrgr
Rollup of 6 pull requests
Successful merges:
- #100211 (Refuse to codegen an upstream static.)
- #100277 (Simplify format_args builtin macro implementation.)
- #100483 (Point to generic or arg if it's the self type of unsatisfied projection predicate)
- #100506 (change `InlineAsmCtxt` to not talk about `FnCtxt`)
- #100534 (Make code slightly more uniform)
- #100566 (Use `create_snapshot_for_diagnostic` instead of `clone` for `Parser`)
bors [Mon, 15 Aug 2022 12:59:53 +0000 (12:59 +0000)]
Auto merge of #98393 - michaelwoerister:new-cpp-like-enum-debuginfo, r=wesleywiser
debuginfo: Generalize C++-like encoding for enums.
The updated encoding should be able to handle niche layouts where more than one variant has fields (as introduced in https://github.com/rust-lang/rust/pull/94075).
The new encoding is more uniform as there is no structural difference between direct-tag, niche-tag, and no-tag layouts anymore. The only difference between those cases is that the "dataful" variant in a niche-tag enum will have a `(start, end)` pair denoting the tag range instead of a single value.
The new encoding now also supports 128-bit tags, which occur in at least some standard library types. These tags are represented as `u64` pairs so that debuggers (which don't always have support for 128-bit integers) can reliably deal with them. The downside is that this adds quite a bit of complexity to the encoding and especially to the corresponding NatVis.
The new encoding seems to increase the size of (x86_64-pc-windows-msvc) debuginfo by 10-15%. The size of binaries is not affected (release builds were built with `-Cdebuginfo=2`, numbers are in kilobytes):
Given that the new encoding is more general, this is to be expected. Only platforms using C++-like debuginfo are affected -- which currently is only `*-pc-windows-msvc`.
*TODO*
- [x] Properly update documentation
- [x] Add regression tests for new optimized enum layouts as introduced by #94075.
projects / rust.git / log