Commit Graph

35848 Commits

Author SHA1 Message Date
Michael Goulet
5e606c0bde Lift Lift 2024-05-10 15:44:03 -04:00
bors
6a19a87097 Auto merge of #124972 - matthiaskrgr:rollup-3fablim, r=matthiaskrgr
Rollup of 5 pull requests

Successful merges:

 - #124615 (coverage: Further simplify extraction of mapping info from MIR)
 - #124778 (Fix parse error message for meta items)
 - #124797 (Refactor float `Primitive`s to a separate `Float` type)
 - #124888 (Migrate `run-make/rustdoc-output-path` to rmake)
 - #124957 (Make `Ty::builtin_deref` just return a `Ty`)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-05-10 16:04:26 +00:00
Matthias Krüger
9a9ec90567
Rollup merge of #124957 - compiler-errors:builtin-deref, r=michaelwoerister
Make `Ty::builtin_deref` just return a `Ty`

Nowhere in the compiler are we using the mutability part of the `TyAndMut` that we used to return.
2024-05-10 16:10:47 +02:00
Matthias Krüger
1ae0d90b72
Rollup merge of #124797 - beetrees:primitive-float, r=davidtwco
Refactor float `Primitive`s to a separate `Float` type

Now there are 4 of them, it makes sense to refactor `F16`, `F32`, `F64` and `F128` out of `Primitive` and into a separate `Float` type (like integers already are). This allows patterns like `F16 | F32 | F64 | F128` to be simplified into `Float(_)`, and is consistent with `ty::FloatTy`.

As a side effect, this PR also makes the `Ty::primitive_size` method work with `f16` and `f128`.

Tracking issue: #116909

`@rustbot` label +F-f16_and_f128
2024-05-10 16:10:46 +02:00
Matthias Krüger
f605174ea7
Rollup merge of #124778 - fmease:fix-diag-msg-parse-meta-item, r=nnethercote
Fix parse error message for meta items

Addresses https://github.com/rust-lang/rust/issues/122796#issuecomment-2010803906, cc [``@]Thomasdezeeuw.``

For attrs inside of a macro like `#[doc(alias = $ident)]` or `#[cfg(feature = $ident)]` where `$ident` is a macro metavariable of fragment kind `ident`, we used to say the following when expanded (with `$ident` ⟼ `ident`):

```
error: expected unsuffixed literal or identifier, found `ident`
  --> weird.rs:6:19
   |
6  |      #[cfg(feature = $ident)]
   |                      ^^^^^^
...
11 | m!(id);
   | ------ in this macro invocation
   |
   = note: this error originates in the macro `m` (in Nightly builds, run with -Z macro-backtrace for more info)
```

This was incorrect and caused confusion, justifiably so (see #122796).

In this position, we only accept/expect *unsuffixed literals* which consist of numeric & string literals as well as the boolean literals / the keywords / the reserved identifiers `false` & `true` **but not** arbitrary identifiers.

Furthermore, we used to suggest garbage when encountering unexpected non-identifier tokens:

```
error: expected unsuffixed literal, found `-`
  --> weird.rs:16:17
   |
16 | #[cfg(feature = -1)]
   |                 ^
   |
help: surround the identifier with quotation marks to parse it as a string
   |
16 | #[cfg(feature =" "-1)]
   |                + +
```

Now we no longer do.
2024-05-10 16:10:45 +02:00
Matthias Krüger
c768a0e99f
Rollup merge of #124615 - Zalathar:extracted-mappings, r=davidtwco
coverage: Further simplify extraction of mapping info from MIR

This is another round of rearrangement and simplification that builds on top of the changes made to mapping-extraction by #124603.

The overall theme is to take the computation of `bcb_has_mappings` and `test_vector_bitmap_bytes` out of the main body of `generate_coverage_spans`, which then lets us perform a few other small changes that had previously been held up by the need to work around those computations.
2024-05-10 16:10:45 +02:00
bors
66f877007d Auto merge of #124932 - RalfJung:temporal, r=compiler-errors
codegen: memmove/memset cannot be non-temporal

non-temporal memset is not a thing.
And for memmove, since the LLVM backend doesn't support this, surely we don't need it in the GCC backend.
2024-05-10 13:55:59 +00:00
León Orell Valerian Liehr
0ad3c5da72
Fix parse error message for meta items 2024-05-10 09:16:27 +02:00
bors
f7b1501ce7 Auto merge of #124961 - matthiaskrgr:rollup-1jj65p6, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #124551 (Add benchmarks for `impl Debug for str`)
 - #124915 (`rustc_target` cleanups)
 - #124918 (Eliminate some `FIXME(lcnr)` comments)
 - #124927 (opt-dist: use xz2 instead of xz crate)
 - #124936 (analyse visitor: build proof tree in probe)
 - #124943 (always use `GenericArgsRef`)
 - #124955 (Use fewer origins when creating type variables.)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-05-10 06:50:46 +00:00
Matthias Krüger
0ee258009c
Rollup merge of #124955 - nnethercote:next_ty_var, r=lcnr
Use fewer origins when creating type variables.

To reduce lots of repetitive boilerplate code. Details in the individual commit messages.

r? ``@lcnr``
2024-05-10 07:30:22 +02:00
Matthias Krüger
30bd6cb726
Rollup merge of #124943 - lcnr:generic-args-ref, r=compiler-errors
always use `GenericArgsRef`

r? ```@compiler-errors```
2024-05-10 07:30:21 +02:00
Matthias Krüger
43ddd1d963
Rollup merge of #124936 - lcnr:cool-beans, r=compiler-errors
analyse visitor: build proof tree in probe

see inline comments

fixes #124791
fixes #124702

r? ```@compiler-errors```
2024-05-10 07:30:21 +02:00
Matthias Krüger
7e4f6082ce
Rollup merge of #124918 - nnethercote:FIXME-lcnr, r=lcnr
Eliminate some `FIXME(lcnr)` comments

In some cases this involved changing code. In some cases the comment was able to removed or replaced.

r? ``@lcnr``
2024-05-10 07:30:20 +02:00
Matthias Krüger
0b4715e7f8
Rollup merge of #124915 - nnethercote:rustc_target-cleanups, r=bjorn3
`rustc_target` cleanups

Minor improvement I found while looking at this code.

r? ```@lqd```
2024-05-10 07:30:19 +02:00
bors
98dabb622a Auto merge of #124953 - compiler-errors:own-params, r=lcnr
Rename `Generics::params` to `Generics::own_params`

I hope this makes it slightly more obvious that `generics.own_params` is insufficient when considering nested items. I didn't actually audit any of the usages, for the record.

r? lcnr
2024-05-10 04:43:57 +00:00
Michael Goulet
d50c2b0a52 Make builtin_deref just return a Ty 2024-05-09 22:55:00 -04:00
Michael Goulet
1c19b6ad60 Rename Generics::params to Generics::own_params 2024-05-09 20:58:46 -04:00
Nicholas Nethercote
df6f7133ee De-tuple two vtable_trait_first_method_offset args.
Thus eliminating a `FIXME` comment.
2024-05-10 09:55:09 +10:00
Nicholas Nethercote
24445d3b6a Remove out-of-date comment.
The use of `Binder` was removed in the recent #123900, but the comment
wasn't removed at the same time.
2024-05-10 09:55:09 +10:00
Nicholas Nethercote
d13612bce7 Remove TyCtxt::try_normalize_erasing_late_bound_regions.
It's unused.
2024-05-10 09:55:09 +10:00
Nicholas Nethercote
5b5dd1b3de Fix out-of-date comment.
The type name has changed.
2024-05-10 09:55:07 +10:00
Nicholas Nethercote
fe843feaab Use fewer origins when creating type variables.
`InferCtxt::next_{ty,const}_var*` all take an origin, but the
`param_def_id` is almost always `None`. This commit changes them to just
take a `Span` and build the origin within the method, and adds new
methods for the rare cases where `param_def_id` might not be `None`.
This avoids a lot of tedious origin building.

Specifically:
- next_ty_var{,_id_in_universe,_in_universe}: now take `Span` instead of
  `TypeVariableOrigin`
- next_ty_var_with_origin: added

- next_const_var{,_in_universe}: takes Span instead of ConstVariableOrigin
- next_const_var_with_origin: added

- next_region_var, next_region_var_in_universe: these are unchanged,
  still take RegionVariableOrigin

The API inconsistency (ty/const vs region) seems worth it for the
large conciseness improvements.
2024-05-10 09:47:46 +10:00
Nicholas Nethercote
11f2ca340c Inline and remove unused methods.
`InferCtxt::next_{ty,const,int,float}_var_id` each have a single call
site, in `InferCtt::next_{ty,const,int,float}_var` respectively.

The only remaining method that creates a var_id is
`InferCtxt::next_ty_var_id_in_universe`, which has one use outside the
crate.
2024-05-10 09:47:22 +10:00
lcnr
8f9062530b always use GenericArgsRef 2024-05-09 19:52:02 +00:00
lcnr
83e6da0be5 analyse visitor: build proof tree in probe 2024-05-09 17:29:53 +00:00
Matthias Krüger
779fe95298
Rollup merge of #124926 - Alexendoo:feature-maybe-incorrect, r=est31
Make `#![feature]` suggestion MaybeIncorrect

Fixes https://github.com/rust-lang/rust-clippy/issues/12784

The `unstable_name_collisions` lint uses `disabled_nightly_features` to mention the feature name, but accepting the suggestion would result in an ambiguity error

There are other calls where accepting the feature gate would fix code when ran with `cargo fix --broken-code`, though it's not always desirable to add a feature gate even if the user is currently on nightly so MaybeIncorrect seems appropriate
2024-05-09 19:09:31 +02:00
Matthias Krüger
a40fa8f443
Rollup merge of #124924 - goofylfg:master, r=est31
chore: remove repetitive words
2024-05-09 19:09:31 +02:00
Matthias Krüger
024881a36b
Rollup merge of #124923 - RalfJung:offset-from-errors, r=compiler-errors
interpret/miri: better errors on failing offset_from

Fixes https://github.com/rust-lang/miri/issues/3104
2024-05-09 19:09:30 +02:00
Matthias Krüger
0a917f89f3
Rollup merge of #124919 - nnethercote:Recovered-Yes-ErrorGuaranteed, r=compiler-errors
Add `ErrorGuaranteed` to `Recovered::Yes` and use it more.

The starting point for this was identical comments on two different fields, in `ast::VariantData::Struct` and `hir::VariantData::Struct`:
```
    // FIXME: investigate making this a `Option<ErrorGuaranteed>`
    recovered: bool
```
I tried that, and then found that I needed to add an `ErrorGuaranteed` to `Recovered::Yes`. Then I ended up using `Recovered` instead of `Option<ErrorGuaranteed>` for these two places and elsewhere, which required moving `ErrorGuaranteed` from `rustc_parse` to `rustc_ast`.

This makes things more consistent, because `Recovered` is used in more places, and there are fewer uses of `bool` and
`Option<ErrorGuaranteed>`. And safer, because it's difficult/impossible to set `recovered` to `Recovered::Yes` without having emitted an error.

r? `@oli-obk`
2024-05-09 19:09:30 +02:00
Matthias Krüger
ebeedf05cb
Rollup merge of #124893 - xldenis:public-region-apis, r=lcnr
Make a minimal amount of region APIs public

Tools like Creusot, Prusti or Gillian-Rust need to access information about the loans and regions that exist in MIR programs. While `rustc` provides information about loans, there is currently no public way to reason about the regions present in a MIR program. In particular, we to know which regions are actually equal to each other and which ones outlive each other. Currently, `rustc` provides access to `RegionInferenceContext` but the public api hides that last portion of the information.

This PR proposes to make a few apis public, allowing verifiers to reason about the lifetimes present in Rust programs:
- [eval_equal](https://doc.rust-lang.org/beta/nightly-rustc/rustc_borrowck/region_infer/struct.RegionInferenceContext.html#method.eval_equal)
- [eval_outlives](https://doc.rust-lang.org/beta/nightly-rustc/rustc_borrowck/region_infer/struct.RegionInferenceContext.html#method.eval_outlives)
- (Optional) [constraint_sccs](https://doc.rust-lang.org/beta/nightly-rustc/rustc_borrowck/region_infer/struct.RegionInferenceContext.html#method.constraint_sccs)

The first two functions would allow us to compare regions and from this we can construct the set of `RegionVid` which are actually equal to each other, and then recover the inclusions between those regions, while the second allows for more direct, but _low level_ access to that information.
2024-05-09 19:09:29 +02:00
Ralf Jung
95582e6fcb codegen: memmove/memset cannot be non-temporal 2024-05-09 18:59:00 +02:00
goofylfg
5120010b02 chore: remove repetitive words 2024-05-09 12:41:48 +00:00
Alex Macleod
3c52553912 Make #![feature] suggestion MaybeIncorrect 2024-05-09 13:18:09 +01:00
Ralf Jung
41d36a0951 interpret/miri: better errors on failing offset_from 2024-05-09 13:09:47 +02:00
Nicholas Nethercote
d6c63bdb21 Fix up DescriptionCtx::new.
The comment mentions that `ReBound` and `ReVar` aren't expected here.
Experimentation with the full test suite indicates this is true, and
that `ReErased` also doesn't occur. So the commit introduces `bug!` for
those cases. (If any of them show up later on, at least we'll have a
test case.)

The commit also remove the first sentence in the comment.
`RePlaceholder` is now handled in the match arm above this comment and
nothing is printed for it, so that sentence is just wrong. Furthermore,
issue #13998 was closed some time ago.
2024-05-09 20:15:44 +10:00
Nicholas Nethercote
609b9a67c9 Correct a comment.
I tried simplifying `RegionCtxt`, which led me to finding that the
fields are printed in `sccs_info`.
2024-05-09 20:15:42 +10:00
Nicholas Nethercote
fd91925bce Add ErrorGuaranteed to Recovered::Yes and use it more.
The starting point for this was identical comments on two different
fields, in `ast::VariantData::Struct` and `hir::VariantData::Struct`:
```
    // FIXME: investigate making this a `Option<ErrorGuaranteed>`
    recovered: bool
```
I tried that, and then found that I needed to add an `ErrorGuaranteed`
to `Recovered::Yes`. Then I ended up using `Recovered` instead of
`Option<ErrorGuaranteed>` for these two places and elsewhere, which
required moving `ErrorGuaranteed` from `rustc_parse` to `rustc_ast`.

This makes things more consistent, because `Recovered` is used in more
places, and there are fewer uses of `bool` and
`Option<ErrorGuaranteed>`. And safer, because it's difficult/impossible
to set `recovered` to `Recovered::Yes` without having emitted an error.
2024-05-09 20:12:07 +10:00
bors
cb93c24bf3 Auto merge of #124157 - wutchzone:partial_eq, r=estebank
Do not add leading asterisk in the `PartialEq`

I think we should address this issue, however I am not exactly sure, if this is the right way to do it. It is related to the #123056.

Imagine the simplified code:

```rust
trait MyTrait {}

impl PartialEq for dyn MyTrait {
    fn eq(&self, _other: &Self) -> bool {
        true
    }
}

#[derive(PartialEq)]
enum Bar {
    Foo(Box<dyn MyTrait>),
}
```

On the nightly compiler, the `derive` produces invalid code with the weird error message:
```
error[E0507]: cannot move out of `*__arg1_0` which is behind a shared reference
  --> src/main.rs:11:9
   |
9  | #[derive(PartialEq)]
   |          --------- in this derive macro expansion
10 | enum Things {
11 |     Foo(Box<dyn MyTrait>),
   |         ^^^^^^^^^^^^^^^^ move occurs because `*__arg1_0` has type `Box<dyn MyTrait>`, which does not implement the `Copy` trait
   |
   = note: this error originates in the derive macro `PartialEq` (in Nightly builds, run with -Z macro-backtrace for more info)
```

It may be related to the perfect derive problem, although requiring the _type_ to be `Copy` seems unfortunate because it is not necessary. Besides, we are adding the extra dereference only for the diagnostics?
2024-05-09 08:34:14 +00:00
bors
5f8c17dcc0 Auto merge of #124916 - matthiaskrgr:rollup-vmpmt4u, r=matthiaskrgr
Rollup of 4 pull requests

Successful merges:

 - #124777 (Fix Error Messages for `break` Inside Coroutines)
 - #124837 (Migrate `run-make/rustdoc-map-file` to rmake)
 - #124875 (Fix more ICEs in `diagnostic::on_unimplemented`)
 - #124908 (Handle field projections like slice indexing in invalid_reference_casting)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-05-09 06:14:00 +00:00
Matthias Krüger
48b1e1a280
Rollup merge of #124908 - saethlin:ref-casting_bigger_place_projection, r=fee1-dead
Handle field projections like slice indexing in invalid_reference_casting

r? `@Urgau`

I saw the implementation in https://github.com/rust-lang/rust/pull/124761, and I was wondering if we also need to handle field access. We do. Without this PR, we get this errant diagnostic:
```
error: casting references to a bigger memory layout than the backing allocation is undefined behavior, even if the reference is unused
  --> /home/ben/rust/tests/ui/lint/reference_casting.rs:262:18
   |
LL |         let r = &mut v.0;
   |                      --- backing allocation comes from here
LL |         let ptr = r as *mut i32 as *mut Vec3<i32>;
   |                   ------------------------------- casting happend here
LL |         unsafe { *ptr = Vec3(0, 0, 0) }
   |                  ^^^^^^^^^^^^^^^^^^^^
   |
   = note: casting from `i32` (4 bytes) to `Vec3<i32>` (12 bytes)
```
2024-05-09 06:04:40 +02:00
Matthias Krüger
c49436df4c
Rollup merge of #124875 - compiler-errors:more-diagnostics-ices, r=estebank
Fix more ICEs in `diagnostic::on_unimplemented`

There were 8 other calls to `expect_local` left in `on_unimplemented.rs` -- all of which (afaict) could be turned into ICEs.

I would really like to see validation of `on_unimplemented` separated from parsing, so we only emit errors here:
a60f077c38/compiler/rustc_hir_analysis/src/check/check.rs (L836-L839)
...And gracefully fail instead when emitting trait predicate failures, not *ever* even trying to emit an error or a lint. But that's left for a separate PR.

r? `@estebank`
2024-05-09 06:04:39 +02:00
Matthias Krüger
9b834d01e5
Rollup merge of #124777 - veera-sivarajan:bugfix-124495-identify-gen-block, r=compiler-errors
Fix Error Messages for `break` Inside Coroutines

Fixes #124495

Previously, `break` inside `gen` blocks and functions
were incorrectly identified to be enclosed by a closure.

This PR fixes it by displaying an appropriate error message
for async blocks, async closures, async functions, gen blocks,
gen closures, gen functions, async gen blocks, async gen closures
and async gen functions.

Note: gen closure and async gen closure are not supported by the
compiler yet but I have added an error message here assuming that
they might be implemented in the future.

~~Also, fixes grammar in a few places by replacing
`inside of a $coroutine` with `inside a $coroutine`.~~
2024-05-09 06:04:38 +02:00
bors
37dc766378 Auto merge of #124831 - nnethercote:rustc_data_structures-cleanups, r=michaelwoerister
`rustc_data_structures` cleanups

Some improvements I found while looking through this code.

r? `@michaelwoerister`
2024-05-09 04:04:09 +00:00
Nicholas Nethercote
69b86f6cae Remove unused LinkSelfContainedDefault::is_linker_enabled method. 2024-05-09 10:54:38 +10:00
Nicholas Nethercote
58a06b6a99 Remove enum_from_u32.
It's a macro that just creates an enum with a `from_u32` method. It has
two arms. One is unused and the other has a single use.

This commit inlines that single use and removes the whole macro. This
increases readability because we don't have two different macros
interacting (`enum_from_u32` and `language_item_table`).
2024-05-09 09:01:59 +10:00
Nicholas Nethercote
d3d01e1cd3 Remove vec_linked_list.
It provides a way to effectively embed a linked list within an
`IndexVec` and also iterate over that list. It's written in a very
generic way, involving two traits `Links` and `LinkElem`. But the
`Links` trait is only impl'd for `IndexVec` and `&IndexVec`, and the
whole thing is only used in one module within `rustc_borrowck`. So I
think it's over-engineered and hard to read. Plus it has no comments.

This commit removes it, and adds a (non-generic) local iterator for the
use within `rustc_borrowck`. Much simpler.
2024-05-09 08:13:24 +10:00
Nicholas Nethercote
f5d7d346a4 Remove TinyList.
It is optimized for lists with a single element, avoiding the need for
an allocation in that case. But `SmallVec<[T; 1]>` also avoids the
allocation, and is better in general: more standard, log2 number of
allocations if the list exceeds one item, and a much more capable API.

This commit removes `TinyList` and converts the two uses to
`SmallVec<[T; 1]>`. It also reorders the `use` items in the relevant
file so they are in just two sections (`pub` and non-`pub`), ordered
alphabetically, instead of many sections. (This is a relevant part of
the change because I had to decide where to add a `use` item for
`SmallVec`.)
2024-05-09 08:13:24 +10:00
Nicholas Nethercote
d7814e72eb Document Pu128.
And move the `repr` line after the `derive` line, where it's harder to
overlook. (I overlooked it initially, and didn't understand how this
type worked.)
2024-05-09 08:13:24 +10:00
Matthias Krüger
782ef18168
Rollup merge of #124909 - compiler-errors:struct-tail-leftovers, r=compiler-errors
Reapply the part of #124548 that bors forgot

https://github.com/rust-lang/rust/pull/124548#issuecomment-2101311205
r? compiler-errors
2024-05-08 23:33:28 +02:00
Matthias Krüger
294ac1b57d
Rollup merge of #124892 - jfgoog:update-cc, r=workingjubilee
Update cc crate to v1.0.97
2024-05-08 23:33:27 +02:00