Commit Graph

249819 Commits

Author SHA1 Message Date
Esteban Küber
cc9631a371 When displaying multispans, ignore empty lines adjacent to ...
```
error[E0308]: `match` arms have incompatible types
   --> tests/ui/codemap_tests/huge_multispan_highlight.rs:98:18
    |
6   |       let _ = match true {
    |               ---------- `match` arms have incompatible types
7   |           true => (
    |  _________________-
8   | |             // last line shown in multispan header
...   |
96  | |
97  | |         ),
    | |_________- this is found to be of type `()`
98  |           false => "
    |  __________________^
...   |
119 | |
120 | |         ",
    | |_________^ expected `()`, found `&str`

error[E0308]: `match` arms have incompatible types
   --> tests/ui/codemap_tests/huge_multispan_highlight.rs:215:18
    |
122 |       let _ = match true {
    |               ---------- `match` arms have incompatible types
123 |           true => (
    |  _________________-
124 | |
125 | |         1 // last line shown in multispan header
...   |
213 | |
214 | |         ),
    | |_________- this is found to be of type `{integer}`
215 |           false => "
    |  __________________^
216 | |
217 | |
218 | |         1 last line shown in multispan
...   |
237 | |
238 | |         ",
    | |_________^ expected integer, found `&str`
```
2024-03-18 16:25:36 +00:00
Esteban Küber
8ea7177af7 Move multispan test to svg output 2024-03-18 16:25:36 +00:00
Esteban Küber
3e0bf9498a Fix test for multiline span ui display
The compiler output changed in such a way that this test was no longer testing what it was meant to.
2024-03-18 16:25:36 +00:00
bors
3cdcdaf31b Auto merge of #122646 - saethlin:library-frame-pointers, r=onur-ozkan
Enable frame pointers for the standard library

There's been a few past experiments for enabling frame pointers for all our artifacts. I don't think that frame pointers in the distributed compiler are nearly as useful as frame pointers in the standard library. Our users are much more likely to be profiling apps written in Rust than they are profiling the Rust compiler.

So yeah it would be cool to have frame pointers in the compiler, but much more of the value is having them on the precompiled standard library. That's what this PR does.
2024-03-18 12:43:41 +00:00
bors
13abc0ac9b Auto merge of #122558 - kjetilkjeka:llvm_bitcode_linker_no_trigger_rebuild, r=onur-ozkan
LLVM bitcode linker: use --cfg=parallel_compiler to avoid invalidating the build cache of rustdoc

fixes #122491

`@rustbot` ready
2024-03-18 09:48:40 +00:00
bors
a42873e85b Auto merge of #122676 - matthiaskrgr:rollup-noti0vr, r=matthiaskrgr
Rollup of 4 pull requests

Successful merges:

 - #122639 (Fix typos)
 - #122654 (interpret/memory: explain why we use == on bool)
 - #122656 (simplify_cfg: rename some passes so that they make more sense)
 - #122657 (Move `option_env!` and `env!` tests to the `env-macro` directory)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-03-18 06:17:15 +00:00
Matthias Krüger
069b93335f
Rollup merge of #122657 - beetrees:option-env-tests, r=compiler-errors,Nilstrieb
Move `option_env!` and `env!` tests to the `env-macro` directory

This PR moves the `option_env!` tests to there own directory (`extoption_env`), matching the naming convention used by the tests for `env!` (which live in the `extenv` directory).
2024-03-18 06:58:50 +01:00
Matthias Krüger
3fc3142df1
Rollup merge of #122656 - RalfJung:simplify-cfg, r=compiler-errors
simplify_cfg: rename some passes so that they make more sense

I was extremely confused by `SimplifyCfg::ElaborateDrops`, since it runs way later than drop elaboration. It is used e.g. in `mir-opt/retag.rs` even though that pass doesn't care about drop elaboration at all.

"Early opt" is also very confusing since that makes it sounds like it runs early during optimizations, i.e. on runtime MIR, but actually it runs way before that.

So I decided to rename
- early-opt -> post-analysis
- elaborate-drops -> pre-optimizations

I am open to other suggestions.
2024-03-18 06:58:50 +01:00
Matthias Krüger
86bb0bc41d
Rollup merge of #122654 - RalfJung:interpret-comment, r=matthiaskrgr
interpret/memory: explain why we use == on bool

This came up in https://github.com/rust-lang/rust/pull/122636.
2024-03-18 06:58:49 +01:00
Matthias Krüger
d9b47c1f2b
Rollup merge of #122639 - omahs:patch-2, r=estebank
Fix typos

Fix typos
2024-03-18 06:58:49 +01:00
bors
80e5694d6f Auto merge of #121952 - JarvisCraft:master, r=workingjubilee
feat: implement `{Div,Rem}Assign<NonZero<X>>` on `X`

# Description

This PR implements `DivAssign<X>` and `RemAssign<X>` on `X` as suggested in rust-lang/libs-team#346.

Since this is just a trait implementation on an already stable type, for which non-assign operator traits are already stable, I suggest that it is an insta-stable feature.
2024-03-18 04:15:14 +00:00
bors
5608c7f9aa Auto merge of #121652 - estebank:move-in-loop-break-condition, r=Nadrieril
Detect when move of !Copy value occurs within loop and should likely not be cloned

When encountering a move error on a value within a loop of any kind,
identify if the moved value belongs to a call expression that should not
be cloned and avoid the semantically incorrect suggestion. Also try to
suggest moving the call expression outside of the loop instead.

```
error[E0382]: use of moved value: `vec`
  --> $DIR/recreating-value-in-loop-condition.rs:6:33
   |
LL |     let vec = vec!["one", "two", "three"];
   |         --- move occurs because `vec` has type `Vec<&str>`, which does not implement the `Copy` trait
LL |     while let Some(item) = iter(vec).next() {
   |     ----------------------------^^^--------
   |     |                           |
   |     |                           value moved here, in previous iteration of loop
   |     inside of this loop
   |
note: consider changing this parameter type in function `iter` to borrow instead if owning the value isn't necessary
  --> $DIR/recreating-value-in-loop-condition.rs:1:17
   |
LL | fn iter<T>(vec: Vec<T>) -> impl Iterator<Item = T> {
   |    ----         ^^^^^^ this parameter takes ownership of the value
   |    |
   |    in this function
help: consider moving the expression out of the loop so it is only moved once
   |
LL ~     let mut value = iter(vec);
LL ~     while let Some(item) = value.next() {
   |
```

We use the presence of a `break` in the loop that would be affected by
the moved value as a heuristic for "shouldn't be cloned".

Fix https://github.com/rust-lang/rust/issues/121466.

---

*Point at continue and break that might be in the wrong place*

Sometimes move errors are because of a misplaced `continue`, but we didn't
surface that anywhere. Now when there are more than one set of nested loops
we show them out and point at the `continue` and `break` expressions within
that might need to go elsewhere.

```
error[E0382]: use of moved value: `foo`
  --> $DIR/nested-loop-moved-value-wrong-continue.rs:46:18
   |
LL |     for foo in foos {
   |         ---
   |         |
   |         this reinitialization might get skipped
   |         move occurs because `foo` has type `String`, which does not implement the `Copy` trait
...
LL |         for bar in &bars {
   |         ---------------- inside of this loop
...
LL |                 baz.push(foo);
   |                          --- value moved here, in previous iteration of loop
...
LL |         qux.push(foo);
   |                  ^^^ value used here after move
   |
note: verify that your loop breaking logic is correct
  --> $DIR/nested-loop-moved-value-wrong-continue.rs:41:17
   |
LL |     for foo in foos {
   |     ---------------
...
LL |         for bar in &bars {
   |         ----------------
...
LL |                 continue;
   |                 ^^^^^^^^ this `continue` advances the loop at line 33
help: consider moving the expression out of the loop so it is only moved once
   |
LL ~         let mut value = baz.push(foo);
LL ~         for bar in &bars {
LL |
 ...
LL |             if foo == *bar {
LL ~                 value;
   |
help: consider cloning the value if the performance cost is acceptable
   |
LL |                 baz.push(foo.clone());
   |                             ++++++++
```

Fix https://github.com/rust-lang/rust/issues/92531.
2024-03-18 02:10:34 +00:00
bors
62f98b44cc Auto merge of #122627 - RalfJung:collector-stack-space, r=compiler-errors
collector: move ensure_sufficient_stack out of the loop

According to the docs this call has some overhead to putting it inside the loop doesn't seem like a good idea.

r? `@oli-obk`
2024-03-18 00:03:56 +00:00
Kjetil Kjeka
7bdd63dcdd LLVM bitcode linker: use --cfg=parallell_compiler to avoid trashing the cache of rustdoc 2024-03-17 23:20:40 +01:00
beetrees
36514015ff
Move option_env! and env! tests to the env-macro directory 2024-03-17 21:59:40 +00:00
Esteban Küber
3b237d7d8a Move suggest_hoisting_call_outside_loop out of suggest_cloning 2024-03-17 21:52:12 +00:00
Esteban Küber
da2364d746 Move Visitor impl out to the mod level 2024-03-17 21:46:52 +00:00
Esteban Küber
f216bac861 Add HELP to test 2024-03-17 21:45:03 +00:00
Esteban Küber
78d29ad8d6 Point at continue and break that might be in the wrong place
Sometimes move errors are because of a misplaced `continue`, but we didn't
surface that anywhere. Now when there are more than one set of nested loops
we show them out and point at the `continue` and `break` expressions within
that might need to go elsewhere.

```
error[E0382]: use of moved value: `foo`
  --> $DIR/nested-loop-moved-value-wrong-continue.rs:46:18
   |
LL |     for foo in foos {
   |         ---
   |         |
   |         this reinitialization might get skipped
   |         move occurs because `foo` has type `String`, which does not implement the `Copy` trait
...
LL |         for bar in &bars {
   |         ---------------- inside of this loop
...
LL |                 baz.push(foo);
   |                          --- value moved here, in previous iteration of loop
...
LL |         qux.push(foo);
   |                  ^^^ value used here after move
   |
note: verify that your loop breaking logic is correct
  --> $DIR/nested-loop-moved-value-wrong-continue.rs:41:17
   |
LL |     for foo in foos {
   |     ---------------
...
LL |         for bar in &bars {
   |         ----------------
...
LL |                 continue;
   |                 ^^^^^^^^ this `continue` advances the loop at line 33
help: consider moving the expression out of the loop so it is only moved once
   |
LL ~         let mut value = baz.push(foo);
LL ~         for bar in &bars {
LL |
 ...
LL |             if foo == *bar {
LL ~                 value;
   |
help: consider cloning the value if the performance cost is acceptable
   |
LL |                 baz.push(foo.clone());
   |                             ++++++++
```

Fix #92531.
2024-03-17 21:32:26 +00:00
Esteban Küber
14473adf42 Detect when move of !Copy value occurs within loop and should likely not be cloned
When encountering a move error on a value within a loop of any kind,
identify if the moved value belongs to a call expression that should not
be cloned and avoid the semantically incorrect suggestion. Also try to
suggest moving the call expression outside of the loop instead.

```
error[E0382]: use of moved value: `vec`
  --> $DIR/recreating-value-in-loop-condition.rs:6:33
   |
LL |     let vec = vec!["one", "two", "three"];
   |         --- move occurs because `vec` has type `Vec<&str>`, which does not implement the `Copy` trait
LL |     while let Some(item) = iter(vec).next() {
   |     ----------------------------^^^--------
   |     |                           |
   |     |                           value moved here, in previous iteration of loop
   |     inside of this loop
   |
note: consider changing this parameter type in function `iter` to borrow instead if owning the value isn't necessary
  --> $DIR/recreating-value-in-loop-condition.rs:1:17
   |
LL | fn iter<T>(vec: Vec<T>) -> impl Iterator<Item = T> {
   |    ----         ^^^^^^ this parameter takes ownership of the value
   |    |
   |    in this function
help: consider moving the expression out of the loop so it is only moved once
   |
LL ~     let mut value = iter(vec);
LL ~     while let Some(item) = value.next() {
   |
```

We use the presence of a `break` in the loop that would be affected by
the moved value as a heuristic for "shouldn't be cloned".

Fix #121466.
2024-03-17 21:32:26 +00:00
bors
eb45c84440 Auto merge of #122653 - matthiaskrgr:rollup-28h37ym, r=matthiaskrgr
Rollup of 6 pull requests

Successful merges:

 - #120640 (Mark UEFI std support as WIP)
 - #121862 (Add release notes for 1.77.0)
 - #122572 (add test for #122301 to cover behavior that's on stable)
 - #122578 (Only invoke `decorate` if the diag can eventually be emitted)
 - #122615 (Mention Zalathar for coverage changes)
 - #122636 (some minor code simplifications)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-03-17 21:06:23 +00:00
Ralf Jung
23a4ad12ce simplify_cfg: rename some passes so that they make more sense 2024-03-17 19:59:15 +01:00
Ralf Jung
872781b226 interpret/memory: explain why we use == on bool 2024-03-17 19:32:03 +01:00
Matthias Krüger
1588d9bdc8
Rollup merge of #122636 - matthiaskrgr:compl3, r=compiler-errors
some minor code simplifications
2024-03-17 19:26:23 +01:00
Matthias Krüger
0589ffb902
Rollup merge of #122615 - Zalathar:triagebot, r=Mark-Simulacrum
Mention Zalathar for coverage changes

Hopefully I don't regret all the extra notifications. 🤞
2024-03-17 19:26:22 +01:00
Matthias Krüger
8e748c0a41
Rollup merge of #122578 - jieyouxu:guard-decorate, r=fee1-dead
Only invoke `decorate` if the diag can eventually be emitted

Lints can call [`trimmed_def_paths`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/print/fn.trimmed_def_paths.html#), such as through manual implementations of `LintDiagnostic` and calling `def_path_str`.

05a2be3def/compiler/rustc_lint/src/lints.rs (L1834-L1839)

The emission of a lint eventually relies on [`TyCtxt::node_lint`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.node_lint), which has a `decorate` closure which is responsible for decorating the diagnostic with "lint stuff". `node_lint` in turn relies on [`lint_level`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/fn.lint_level.html). Within `lint_level`, `decorate` is eventually called just before `Diag::emit` is called to decorate the diagnostic. However, if `-A warnings` or `--cap-lint=allow` are set, or if the unused_must_use lint is explicitly allowed, then `decorate` would be called, which would call `def_path_str`, but the diagnostic would never be emitted and hence would trigger the `must_produce_diag` ICE.

To avoid calling `decorate` when we don't eventually emit the diagnostic, we check that:

- if `--force-warn` is specified, then call `decorate`; otherwise
- if we can emit warnings (or higher), then call `decorate`.

Fixes #121774.
2024-03-17 19:26:22 +01:00
Matthias Krüger
3fbe203cc1
Rollup merge of #122572 - the8472:test-const-deadness, r=RalfJung
add test for #122301 to cover behavior that's on stable

If this ought to be broken it should at least happen intentionally

See #122301
2024-03-17 19:26:21 +01:00
Matthias Krüger
5c761d8cfe
Rollup merge of #121862 - cuviper:relnotes-1.77.0, r=Mark-Simulacrum
Add release notes for 1.77.0

cc `@rust-lang/release`
r? `@Mark-Simulacrum`
2024-03-17 19:26:21 +01:00
Matthias Krüger
3d1b04e031
Rollup merge of #120640 - Ayush1325:uefi-doc, r=Nilstrieb
Mark UEFI std support as WIP

Currently stdio and alloc support is present with open PRs for some of the other portions.

A prototype of almost all of std support can be found [here](https://github.com/tianocore/rust/tree/uefi-master). I will be up-streaming as much stuff as possible from there.
2024-03-17 19:26:20 +01:00
Josh Stone
87c9349e1b Sort the remaining T-types relnotes 2024-03-17 09:58:28 -07:00
Josh Stone
8953306016 No compatibility notes raised in 1.77.0 2024-03-17 09:58:28 -07:00
Josh Stone
4a2f0f6c99 The const-eval change is now future-compat 2024-03-17 09:58:28 -07:00
Josh Stone
213e598fae Move a couple issues to Language notes 2024-03-17 09:58:27 -07:00
Josh Stone
0ac3d4df6d Apply suggestions from code review
Co-authored-by: Urgau <3616612+Urgau@users.noreply.github.com>
Co-authored-by: Michael Howell <michael@notriddle.com>
2024-03-17 09:58:27 -07:00
Josh Stone
01864e282a Add release notes for 1.77.0 2024-03-17 09:58:27 -07:00
Ayush Singh
c1cf422140
Mark UEFI std support as WIP
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
2024-03-17 21:32:50 +05:30
Ben Kimock
aeb3447f61 Enable frame pointers for the library 2024-03-17 12:01:18 -04:00
许杰友 Jieyou Xu (Joe)
bdab02ca99
Guard decorate on when not to skip instead 2024-03-17 15:07:22 +00:00
许杰友 Jieyou Xu (Joe)
60de7554de
Invoke decorate when error level is beyond warning, including error 2024-03-17 14:41:37 +00:00
许杰友 Jieyou Xu (Joe)
772d8598d2
Only invoke decorate if the diag can eventually be emitted 2024-03-17 14:41:36 +00:00
Ralf Jung
ee746fb8ed collector: move ensure_sufficient_stack out of the loop 2024-03-17 15:17:00 +01:00
Petr Portnov
e7d397024f
chore(121952): echo comments on the *_assign methods 2024-03-17 17:06:12 +03:00
Petr Portnov
5ebed0ba4b
chore(121952): remove redundant comments
These were only relevant for the unsafe-containing implementations

Signed-off-by: Petr Portnov <me@progrm-jarvis.ru>
2024-03-17 17:00:48 +03:00
Petr Portnov
b186f40b8b
feat: implement {Div,Rem}Assign<NonZero<X>> on X
Signed-off-by: Petr Portnov <me@progrm-jarvis.ru>
2024-03-17 17:00:44 +03:00
The 8472
fefd06dc02 add test for #122301 to cover behavior that's on stable
if this ought to be broken it should at least happen intentionally
2024-03-17 14:58:22 +01:00
bors
35dfc67d94 Auto merge of #122637 - matthiaskrgr:rollup-bczj5bp, r=matthiaskrgr
Rollup of 3 pull requests

Successful merges:

 - #121236 (Don't show suggestion if slice pattern is not top-level)
 - #121787 (run change tracker even when config parse fails)
 - #122633 (avoid unnecessary collect())

r? `@ghost`
`@rustbot` modify labels: rollup
2024-03-17 13:55:27 +00:00
omahs
758f642c29
fix typo 2024-03-17 14:25:24 +01:00
omahs
96e3c2c1ac
fix typo 2024-03-17 14:25:06 +01:00
Matthias Krüger
12137462b4
Rollup merge of #122633 - matthiaskrgr:col, r=fmease
avoid unnecessary collect()
2024-03-17 14:04:15 +01:00
Matthias Krüger
2448162729
Rollup merge of #121787 - onur-ozkan:improve-change-tracker, r=albertlarsan68
run change tracker even when config parse fails

Please note that we are currently validating the build configuration on two entry points (e.g., profile validation is handled on the python side), and change tracker system is handled on the rust side. Once #94829 is completed (scheduled for 2024), we will be able to handle this more effectively.

Fixes #121756
2024-03-17 14:04:14 +01:00