Commit Graph

242199 Commits

Author SHA1 Message Date
Michael Goulet
e24da8ea19 Movability doesn't need to be a query anymore 2023-12-28 16:35:01 +00:00
Michael Goulet
15ccf2e7bd Restore movability to SMIR 2023-12-28 16:35:01 +00:00
Michael Goulet
fcb42b42d6 Remove movability from TyKind::Coroutine 2023-12-28 16:35:01 +00:00
Jakub Beránek
8763f7ae7d
Remove --enable-missing-tools from configure.py 2023-12-28 16:08:39 +01:00
Jakub Beránek
23994e1d76
Remove --enable-missing-tools usage in CI 2023-12-28 16:08:39 +01:00
onur-ozkan
12190e5dd2 utilize the unused llvm-tools option
This field was not functioning as described in its comment in `config.example.toml`.
Also, updated the default value to `true` to keep the bootstrapping behavior as it was before.

Signed-off-by: onur-ozkan <work@onurozkan.dev>
2023-12-28 17:27:59 +03:00
Lieselotte
7d6cd6bf1f
Don't expect bodyless arms if the pattern can never be a never pattern 2023-12-28 15:02:17 +01:00
Dominic
a88c9a644c
Add regression test for #106630 2023-12-28 14:53:23 +01:00
Lieselotte
44bf2a32a5
Update parse_seq doc 2023-12-28 14:06:51 +01:00
bors
f4d794ea0b Auto merge of #119368 - coder-s-cat:master, r=WaffleLapkin
Fix some comments
2023-12-28 09:33:44 +00:00
cuishuang
1adf0c16ff Fix some comments
Signed-off-by: cuishuang <imcusg@gmail.com>
2023-12-28 12:23:14 +08:00
bors
928b3dac57 Auto merge of #119349 - zetanumbers:liveness-pass-refactor, r=WaffleLapkin
refactor(liveness): move walk_expr outside of every match branch
2023-12-28 02:00:02 +00:00
bors
8e34642262 Auto merge of #119336 - Zalathar:find-ancestor, r=petrochenkov
coverage: Unexpand spans with `find_ancestor_inside_same_ctxt`

Back in https://github.com/rust-lang/rust/pull/118525#discussion_r1412877621 it was observed that our `unexpand_into_body_span` now looks very similar to `Span::find_ancestor_inside`.

At the time I tried switching over, but doing so resulted in incorrect coverage mappings (or assertion failures), so I left a `FIXME` comment instead.

After some investigation, I identified the two problems with my original approach:
- I should have been using `find_ancestor_inside_same_ctxt` instead, since we want a span that's inside the body and has the same context as the body.
- For async functions, we were actually using the post-expansion body span, which is why we needed to forcibly set the unexpanded span's context to match the body span. For body spans produced by macro-expansion, we already have special-case code to detect this and use the pre-expansion call site as the body span. By making this code also detect async desugaring, I was able to end up with a body span that works properly with `find_ancestor_inside_same_ctxt`, avoiding the need to forcibly change the span context.
2023-12-28 00:04:05 +00:00
bors
89e2160c4c Auto merge of #119105 - dtolnay:paren, r=WaffleLapkin
Fix parenthesization of subexprs containing statement boundary

This PR fixes a multitude of false negatives and false positives in the AST pretty printer's parenthesis insertion related to statement boundaries &mdash; statements which terminate unexpectedly early if there aren't parentheses.

Without this fix, the AST pretty printer (including both `stringify!` and `rustc -Zunpretty=expanded`) is prone to producing output which is not syntactically valid Rust. Invalid output is problematic because it means Rustfmt is unable to parse the output of `cargo expand`, for example, causing friction by forcing someone trying to debug a macro into reading poorly formatted code.

I believe the set of bugs fixed in this PR account for the most prevalent reason that `cargo expand` produces invalid output in real-world usage.

Fixes #98790.

## False negatives

The following is a correct program &mdash; `cargo check` succeeds.

```rust
macro_rules! m {
    ($e:expr) => {
        match () { _ => $e }
    };
}

fn main() {
    m!({ 1 } - 1);
}
```

But `rustc -Zunpretty=expanded main.rs` produces output that is invalid Rust syntax, because parenthesization is needed and not being done by the pretty printer.

```rust
fn main() { match () { _ => { 1 } - 1, }; }
```

Piping this expanded code to rustfmt, it fails to parse.

```console
error: unexpected `,` in pattern
 --> <stdin>:1:38
  |
1 | fn main() { match () { _ => { 1 } - 1, }; }
  |                                      ^
  |
help: try adding parentheses to match on a tuple...
  |
1 | fn main() { match () { _ => { 1 } (- 1,) }; }
  |                                   +    +
help: ...or a vertical bar to match on multiple alternatives
  |
1 | fn main() { match () { _ => { 1 } - 1 | }; }
  |                                   ~~~~~
```

Fixed output after this PR:

```rust
fn main() { match () { _ => ({ 1 }) - 1, }; }
```

## False positives

Less problematic, but worth fixing (just like #118726).

```rust
fn main() {
    let _ = match () { _ => 1 } - 1;
}
```

Output of `rustc -Zunpretty=expanded lib.rs` before this PR. There is no reason parentheses would need to be inserted there.

```rust
fn main() { let _ = (match () { _ => 1, }) - 1; }
```

After this PR:

```rust
fn main() { let _ = match () { _ => 1, } - 1; }
```

## Alternatives considered

In this PR I opted to parenthesize only the leading subexpression causing the statement boundary, rather than the entire statement. Example:

```rust
macro_rules! m {
    ($e:expr) => {
        $e
    };
}

fn main() {
    m!(loop { break [1]; }[0] - 1);
}
```

This PR produces the following pretty-printed contents for fn main:

```rust
(loop { break [1]; })[0] - 1;
```

A different equally correct output would be:

```rust
(loop { break [1]; }[0] - 1);
```

I chose the one I did because it is the *only* approach used by handwritten code in the standard library and compiler. There are 4 places where parenthesization is being used to prevent a statement boundary, and in all 4, the developer has chosen to parenthesize the smallest subexpression rather than the whole statement:

b37d43efd9/compiler/rustc_codegen_cranelift/example/alloc_system.rs (L102)

b37d43efd9/compiler/rustc_parse/src/errors.rs (L1021-L1029)

b37d43efd9/library/core/src/future/poll_fn.rs (L151)

b37d43efd9/library/core/src/ops/range.rs (L824-L828)
2023-12-27 21:27:26 +00:00
DaniPopes
826269eddb
Simplify Parser::ident_or_error
Avoid a nested `Result<T, PResult<T>>`.
2023-12-27 21:18:32 +01:00
bors
7343db9ce3 Auto merge of #12029 - torfsen:6459-more-cases-for-redundant-matches!, r=llogiq
6459: Check for redundant `matches!` with `Ready`, `Pending`, `V4`, `V6`

Fixes #6459.

```
changelog: [`redundant_pattern_matching`]: Add checks for `Poll::{Ready,Pending}` and `IpAddr::{V4,V6}` in `matches!`
```
2023-12-27 19:55:39 +00:00
bors
88d69b72b4 Auto merge of #119099 - fmease:always-const-trait-bounds, r=fee1-dead
Introduce `const Trait` (always-const trait bounds)

Feature `const_trait_impl` currently lacks a way to express “always const” trait bounds. This makes it impossible to define generic items like fns or structs which contain types that depend on const method calls (\*). While the final design and esp. the syntax of effects / keyword generics isn't set in stone, some version of “always const” trait bounds will very likely form a part of it. Further, their implementation is trivial thanks to the `effects` backbone.

Not sure if this needs t-lang sign-off though.

(\*):

```rs
#![feature(const_trait_impl, effects, generic_const_exprs)]

fn compute<T: const Trait>() -> Type<{ T::generate() }> { /*…*/ }

struct Store<T: const Trait>
where
    Type<{ T::generate() }>:,
{
    field: Type<{ T::generate() }>,
}
```

Lastly, “always const” trait bounds are a perfect fit for `generic_const_items`.

```rs
#![feature(const_trait_impl, effects, generic_const_items)]

const DEFAULT<T: const Default>: T = T::default();
```

Previously, we (oli, fee1-dead and I) wanted to reinterpret `~const Trait` as `const Trait` in generic const items which would've been quite surprising and not very generalizable.
Supersedes #117530.

---

cc `@oli-obk`

As discussed
r? fee1-dead (or compiler)
2023-12-27 19:24:31 +00:00
Florian Brucker
ebc0588937 6459: Check for redundant matches! with Ready, Pending, V4, V6 2023-12-27 19:10:04 +01:00
bors
a861c8965e Auto merge of #117303 - sjwang05:issue-117245, r=estebank
Suggest `=>` --> `>=` in comparisons

Fixes #117245
2023-12-27 17:26:12 +00:00
bors
c689d32a90 Auto merge of #11981 - y21:eager_int_transmute, r=llogiq
new lint: `eager_transmute`

A small but still hopefully useful lint that looks for patterns such as `(x < 5).then_some(transmute(x))`.
This is almost certainly wrong because it evaluates the transmute eagerly and can lead to surprises such as the check being completely removed and always evaluating to `Some` no matter what `x` is (it is UB after all when the integer is not a valid bitpattern for the transmuted-to type). [Example](https://godbolt.org/z/xoY34fPzh).
The user most likely meant to use `then` instead.

I can't remember where I saw this but this is inspired by a real bug that happened in practice.

This could probably be a correctness lint?

changelog: new lint: [`eager_int_transmute`]
2023-12-27 15:16:46 +00:00
bors
15755f38cd Auto merge of #119302 - Mark-Simulacrum:relative-spans, r=WaffleLapkin
Support encoding spans with relative offsets

The relative offset is often smaller than the absolute offset, and with
the LEB128 encoding, this ends up cutting the overall metadata size
considerably (~1.5 megabytes on libcore). We can support both relative
and absolute encodings essentially for free since we already take a full
byte to differentiate between direct and indirect encodings (so an extra
variant is quite cheap).
2023-12-27 14:55:18 +00:00
zetanumbers
4bb7a122bb move walk_expr outside of every match branch 2023-12-27 17:29:31 +03:00
y21
08d8ca9edd new lint: eager_int_transmute 2023-12-27 14:16:35 +01:00
Zalathar
be6b059169 coverage: Unexpand spans with find_ancestor_inside_same_ctxt 2023-12-27 23:49:31 +11:00
Mark Rousskov
9c5293c27b Support relative offsets when encoding spans
The relative offset is often smaller than the absolute offset, and with
the LEB128 encoding, this ends up cutting the overall metadata size
considerably (~1.5 megabytes on libcore). We can support both relative
and absolute encodings essentially for free since we already take a full
byte to differentiate between direct and indirect encodings (so an extra
variant is quite cheap).
2023-12-27 07:31:38 -05:00
León Orell Valerian Liehr
3eb48a35c8
Introduce const Trait (always-const trait bounds) 2023-12-27 12:51:32 +01:00
bors
ca9ff83f1b Auto merge of #119327 - notriddle:notriddle/plusencoding, r=GuillaumeGomez
rustdoc: treat query string `+` as space

Fixes #119219
2023-12-27 11:47:24 +00:00
bors
677f8d8a3c Auto merge of #12018 - waywardmonkeys:doc-markdown-allow-webgpu-webgl2, r=blyxyas
[doc_markdown]: Add "WebGL2", "WebGPU" to default `doc_valid_idents`

changelog: [`doc_markdown`]: Add "WebGL2", "WebGPU" to default `doc_valid_idents`
2023-12-27 11:26:36 +00:00
bors
df5d53585a Auto merge of #119343 - matthiaskrgr:rollup-vkt8lst, r=matthiaskrgr
Rollup of 2 pull requests

Successful merges:

 - #119175 (fix: diagnostic for casting reference to slice)
 - #119337 (Remove dead codes)

r? `@ghost`
`@rustbot` modify labels: rollup
2023-12-27 09:46:51 +00:00
Matthias Krüger
f05e16a70d
Rollup merge of #119337 - mu001999:dead_code/clean, r=WaffleLapkin
Remove dead codes

Detected by #118257
2023-12-27 09:11:36 +01:00
Matthias Krüger
d6382c785f
Rollup merge of #119175 - veera-sivarajan:fix-cast-to-slice, r=WaffleLapkin
fix: diagnostic for casting reference to slice

fixes:  #118790

Removes `if self.cast_ty.is_trait()` to produce the same diagnostic for cast to slice and trait.
2023-12-27 09:11:35 +01:00
bors
9da44323c9 Auto merge of #119233 - Nadrieril:keep-whole-pat-around, r=compiler-errors
Exhaustiveness: keep the original `thir::Pat` around

This PR makes it possible for exhaustiveness to look at the original `thir::Pat`, which I'll need at least for the [`small_gaps`](https://github.com/rust-lang/rust/pull/118879) lint (without that we can't distinguish inclusive and exclusive ranges within exhaustiveness). This PR is almost entirely lifetime-wrangling.
2023-12-27 07:48:29 +00:00
Young-Flash
9e9353c0da fix broken CI and code review 2023-12-27 15:47:57 +08:00
r01and
33867834bc
Remove dead codes 2023-12-27 07:33:43 +00:00
sjwang05
97cf1c87bd
Suggest => --> >= in conditions 2023-12-26 20:59:14 -08:00
bors
625c2c401f Auto merge of #119334 - weihanglo:update-cargo, r=weihanglo
Update cargo

7 commits in 363a2d11320faf531f6aacd1ea067c6bc08343b9..ac6bbb33293d8d424c17ecdb42af3aac25fb7295
2023-12-22 03:12:42 +0000 to 2023-12-26 23:22:08 +0000
- docs: fix link to nightly doc of cargo-util-schemas (rust-lang/cargo#13209)
- doc: improve word usage (rust-lang/cargo#13206)
- fix: clarify `--path` is the installation source not destination (rust-lang/cargo#13205)
- refactor: give some better examples for package ID spec (rust-lang/cargo#13202)
- chore: fix a typo (rust-lang/cargo#13201)
- Extend the build directive syntax with `cargo::` (rust-lang/cargo#12201)
- Rework `--check-cfg` generation comment (rust-lang/cargo#13195)

r? ghost
2023-12-27 03:04:03 +00:00
Weihang Lo
eb84788b67
Update cargo 2023-12-26 21:04:15 -05:00
Michael Howell
0ea58e2346 rustdoc-search: count path edits with separate edit limit
Since the two are counted separately elsewhere, they should get
their own limits, too. The biggest problem with combining them
is that paths are loosely checked by not requiring every component
to match, which means that if they are short and matched loosely,
they can easily find "drunk typist" matches that make no sense,
like this old result:

    std::collections::btree_map::itermut matching slice::itermut
    maxEditDistance = ("slice::itermut".length) / 3 = 14 / 3 = 4
    editDistance("std", "slice") = 4
    editDistance("itermut", "itermut") = 0
        4 + 0 <= 4 PASS

Of course, `slice::itermut` should not match stuff from btreemap.
`slice` should not match `std`.

The new result counts them separately:

    maxPathEditDistance = "slice".length / 3 = 5 / 3 = 1
    maxEditDistance = "itermut".length / 3 = 7 / 3 = 2
    editDistance("std", "slice") = 4
        4 <= 1 FAIL

Effectively, this makes path queries less "typo-resistant".
It's not zero, but it means `vec` won't match the `v1` prelude.

Queries without parent paths are unchanged.
2023-12-26 18:46:17 -07:00
bors
eee93d8396 Auto merge of #119328 - estebank:might_coerce_eq_typo, r=compiler-errors
Suggest `=` to `==` in more cases, even in the face of reference mismatch

Given `foo: &String` and `bar: str`, suggest `==` when given `if foo = bar {}`:

```
error[E0308]: mismatched types
  --> $DIR/assignment-expected-bool.rs:37:8
   |
LL |     if foo = bar {}
   |        ^^^^^^^^^ expected `bool`, found `()`
   |
help: you might have meant to compare for equality
   |
LL |     if foo == bar {}
   |             +
```
2023-12-27 00:22:27 +00:00
Esteban Küber
dc30eb1967 Suggest = to == in more cases, even in the face of reference mismatch
Given `foo: &String` and `bar: str`, suggest `==` when given `if foo = bar {}`:

```
error[E0308]: mismatched types
  --> $DIR/assignment-expected-bool.rs:37:8
   |
LL |     if foo = bar {}
   |        ^^^^^^^^^ expected `bool`, found `()`
   |
help: you might have meant to compare for equality
   |
LL |     if foo == bar {}
   |             +
```
2023-12-26 23:48:55 +00:00
Nadrieril
fc0be3c921 Keep reference to the original Pat in DeconstructedPat 2023-12-26 23:14:23 +01:00
Bruce Mitchener
f48b850c65 [doc_markdown]: Add "WebGL2", "WebGPU" to default doc_valid_idents 2023-12-26 16:58:43 -05:00
bors
2df6406b88 Auto merge of #118431 - sjwang05:issue-44695, r=estebank
Emit better suggestions for `&T == T` and `T == &T`

Fixes #40660
Fixes #44695
2023-12-26 21:34:24 +00:00
Michael Howell
624885d242 rustdoc: treat query string + as space
Fixes #119219
2023-12-26 14:14:28 -07:00
bors
cda17014fa Auto merge of #12022 - xFrednet:changelog-1-75, r=llogiq
Fix typo in changelog for 1.75

Roses are red,
violets are blue,
another typo fixed,
thanks to you `@llogiq`

---

r? `@llogiq`

changelog: none
2023-12-26 20:34:01 +00:00
xFrednet
ae4ab9e369
Fix typo in changelog for 1.75 2023-12-26 20:52:05 +01:00
bors
deace71034 Auto merge of #119324 - compiler-errors:rollup-c6eqcg9, r=compiler-errors
Rollup of 5 pull requests

Successful merges:

 - #119235 (Add missing feature gate for sanitizer CFI cfgs)
 - #119240 (Make some non-diagnostic-affecting `QPath::LangItem` into regular `QPath`s)
 - #119297 (Pass DeadItem and lint as consistent group in dead-code.)
 - #119307 (Clean up some lifetimes in `rustc_pattern_analysis`)
 - #119323 (add test for coercing never to infinite type)

r? `@ghost`
`@rustbot` modify labels: rollup
2023-12-26 19:28:49 +00:00
bors
eb679c7f34 Auto merge of #12019 - xFrednet:changelog-1-75, r=flip1995
Changelog for Rust 1.75 🎄

Roses are red,
Violets are blue,
Another year of development,
And a strong team, too

---

### The cat of this release:

<img width=500 src="https://cdn2.thecatapi.com/images/49r.gif?api_key=live_iA7QQQ2LdohvDfCghXThmLqVYCZ9kXIwGMcwyJyaYyOTRC8NZSYqykPoc2UypsMi" alt="The cats of this Clippy release" />

<sub>The cat for the next release can be nominated in the comments</sub>

---

changelog: none
2023-12-26 19:23:16 +00:00
Michael Goulet
a5b3d139b3
Rollup merge of #119323 - lukas-code:test-never-to-infinite, r=compiler-errors
add test for coercing never to infinite type

Closes https://github.com/rust-lang/rust/issues/113197.

This was fixed in https://github.com/rust-lang/rust/pull/118308, probably 1978168c13.
2023-12-26 13:29:14 -05:00
Michael Goulet
e1be642b41
Rollup merge of #119307 - compiler-errors:pat-lifetimes, r=Nadrieril
Clean up some lifetimes in `rustc_pattern_analysis`

This PR removes some redundant lifetimes. I figured out that we were shortening the lifetime of an arena-allocated `&'p DeconstructedPat<'p>` to `'a DeconstructedPat<'p>`, which forced us to carry both lifetimes when we could otherwise carry just one.

This PR also removes and elides some unnecessary lifetimes.

I also cherry-picked 0292eb9bb9b897f5c0926c6a8530877f67e7cc9b, and then simplified more lifetimes in `MatchVisitor`, which should make #119233 a very simple PR!

r? Nadrieril
2023-12-26 13:29:14 -05:00