Commit Graph

355 Commits

Author SHA1 Message Date
Matthias Krüger
480c4a18d5
Rollup merge of #107201 - compiler-errors:confusing-async-fn-note, r=estebank
Remove confusing 'while checking' note from opaque future type mismatches

Maybe I'm just misinterpreting the wording of the note. The only value I can see in this note is that it points out where the async's opaque future is coming from, but the way it's doing it is misleading IMO.

For example:

```rust
note: while checking the return type of the `async fn`
  --> $DIR/dont-suggest-missing-await.rs:7:24
   |
LL | async fn make_u32() -> u32 {
   |                        ^^^ checked the `Output` of this `async fn`, found opaque type
```

We point at the type `u32` in the HIR, but then say "found opaque type". We also say "while checking"... but we're typechecking a totally different function when we get this type mismatch!

r? ``@estebank`` but feel free to reassign and/or take your time reviewing this. I'd be inclined to also discuss reworking the presentation of this type mismatch to restore some of these labels in a way that makes it more clear what it's trying to point out.
2023-02-02 06:52:13 +01:00
Xiretza
87ef37dbd7 rustc_parse: migrate more to diagnostic structs 2023-02-01 21:50:34 +01:00
Xiretza
ac9c66bff5 tests: rename test cases to match new behaviour 2023-02-01 21:50:34 +01:00
Xiretza
0757d5f83f Fix condition for "missing struct" diagnostic on tuple structs
The check previously matched this, and suggested adding a missing
`struct`:

pub Foo(...):

It was probably intended to match this instead (semicolon instead of
colon):

pub Foo(...);
2023-02-01 21:50:34 +01:00
bors
11d96b5930 Auto merge of #107257 - inquisitivecrystal:ffi-attr, r=davidtwco
Strengthen validation of FFI attributes

Previously, `codegen_attrs` validated the attributes `#[ffi_pure]`, `#[ffi_const]`, and `#[ffi_returns_twice]` to make sure that they were only used on foreign functions. However, this validation was insufficient in two ways:

1. `codegen_attrs` only sees items for which code must be generated, so it was unable to raise errors when the attribute was incorrectly applied to macros and the like.
2. the validation code only checked that the item with the attr was foreign, but not that it was a foreign function, allowing these attributes to be applied to foreign statics as well.

This PR moves the validation to `check_attr`, which sees all items. It additionally changes the validation to ensure that the attribute's target is `Target::ForeignFunction`, only allowing the attributes on foreign functions and not foreign statics. Because these attributes are unstable, there is no risk for backwards compatibility. The changes also ending up making the code much easier to read.

This PR is best reviewed commit by commit. Additionally, I was considering moving the tests to the `attribute` subdirectory, to get them out of the general UI directory. I could do that as part of this PR or a follow-up, as the reviewer prefers.

CC: #58328, #58329
2023-02-01 11:37:24 +00:00
Matthias Krüger
f41f154dfb
Rollup merge of #107533 - pnkfelix:distinguish-generator-state-in-print-type-sizes, r=compiler-errors
Extend `-Z print-type-sizes` to distinguish generator upvars+locals from "normal" fields.

For example, for this code:

```rust
async fn wait() {}

async fn test(arg: [u8; 8192]) {
    wait().await;
    drop(arg);
}

async fn test_ideal(_rg: [u8; 8192]) {
    wait().await;
    // drop(arg);
}

fn main() {
    let gen_t = test([0; 8192]);
    let gen_i = test_ideal([0; 8192]);
    println!("expect {}, got: {}",
             std::mem::size_of_val(&gen_i),
             std::mem::size_of_val(&gen_t));
}
```

the `-Z print-type-sizes` output used to start with:

```
print-type-size type: `[async fn body@issue-62958-a.rs:3:32: 6:2]`: 16386 bytes, alignment: 1 bytes
print-type-size     discriminant: 1 bytes
print-type-size     variant `Suspend0`: 16385 bytes
print-type-size         field `.arg`: 8192 bytes, offset: 0 bytes, alignment: 1 bytes
print-type-size         field `.arg`: 8192 bytes
print-type-size         field `.__awaitee`: 1 bytes
...
print-type-size type: `std::mem::ManuallyDrop<[u8; 8192]>`: 8192 bytes, alignment: 1 bytes
print-type-size     field `.value`: 8192 bytes
...
```

but with this change, it now instead prints:

```
print-type-size type: `[async fn body@issue-62958-a.rs:3:32: 6:2]`: 16386 bytes, alignment: 1 bytes
print-type-size     discriminant: 1 bytes
print-type-size     variant `Suspend0`: 16385 bytes
print-type-size         upvar `.arg`: 8192 bytes, offset: 0 bytes, alignment: 1 bytes
print-type-size         local `.arg`: 8192 bytes
print-type-size         local `.__awaitee`: 1 bytes
...
print-type-size type: `std::mem::ManuallyDrop<[u8; 8192]>`: 8192 bytes, alignment: 1 bytes
print-type-size     field `.value`: 8192 bytes
```

(spawned off of investigation of https://github.com/rust-lang/rust/issues/62958 )
2023-02-01 05:54:40 +01:00
Matthias Krüger
a37a59f45e
Rollup merge of #107499 - compiler-errors:deduce_sig_from_projection-generator-tweak, r=michaelwoerister
Do not depend on Generator trait when deducing closure signature

1. Do not depend on `Generator` trait when deducing closure signature.
2. Compare the name of the `Generator::Return` associated item, rather than its order in the trait. Seems more stable this way.
2023-02-01 05:54:39 +01:00
Matthias Krüger
6390d25eab
Rollup merge of #107487 - edward-shen:edward-shen/107213-round-2, r=estebank
Make the "extra if in let...else block" hint a suggestion

Changes the hint to a suggestion, suggested in #107213.

r? ```@estebank```
2023-02-01 05:54:39 +01:00
Matthias Krüger
0d2ab67742
Rollup merge of #107389 - zvavybir:master, r=estebank
Fixing confusion between mod and remainder

Like many programming languages, rust too confuses remainder and modulus.  The `%` operator and the associated `Rem` trait is (as the trait name suggests) the remainder, but since most people are linguistically more familiar with the modulus the documentation sometimes claims otherwise.  This PR tries to fix this problem in rustc.
2023-02-01 05:54:37 +01:00
Felix S. Klock II
362c4fa755 Bless updated output from print-type-sizes tests. 2023-01-31 20:00:54 -05:00
Ralf Jung
dfc4a7b2d0 make unaligned_reference a hard error 2023-01-31 20:28:11 +01:00
bors
f361413cbf Auto merge of #106399 - estebank:type-err-span-label, r=nagisa
Modify primary span label for E0308

Looking at the reactions to https://hachyderm.io/`@ekuber/109622160673605438,` a lot of people seem to have trouble understanding the current output, where the primary span label on type errors talks about the specific types that diverged, but these can be deeply nested type parameters. Because of that we could see "expected i32, found u32" in the label while the note said "expected Vec<i32>, found Vec<u32>". This understandably confuses people. I believe that once people learn to read these errors it starts to make more sense, but this PR changes the output to be more in line with what people might expect, without sacrificing terseness.

Fix #68220.
2023-01-31 13:53:40 +00:00
Michael Goulet
7892cc3c5f Do not depend on Generator trait when deducing closure signature 2023-01-31 02:59:36 +00:00
Yuki Okushi
f95f835470
Rollup merge of #107479 - compiler-errors:probe-can-call-ocx, r=BoxyUwU
Use `ObligationCtxt::new_in_snapshot` in `satisfied_from_param_env`

We can evaluate nested `ConstEvaluatable` obligations in an evaluation probe, which will ICE if we use `ObligationCtxt::new`.

Fixes #107474
Fixes #106666

r? `@BoxyUwU` but feel free to reassign
cc `@JulianKnodt` who i think added this assertion code

Not sure if the rustdoc test is needed, but can't hurt. They're the same root cause, though.
2023-01-31 11:46:25 +09:00
Yuki Okushi
6eeb981a58
Rollup merge of #107245 - compiler-errors:new-solver-unsizing, r=lcnr
Implement unsizing in the new trait solver

This makes hello world compile! Ignore the first commit, that's just #107146 which is waiting on merge.

I'll leave some comments inline about design choices that might be debatable.

r? `@lcnr` (until we have a new trait solver reviewer group...)
2023-01-31 11:46:22 +09:00
bors
487e83b711 Auto merge of #105650 - cassaundra:float-literal-suggestion, r=pnkfelix
Fix invalid float literal suggestions when recovering an integer

Only suggest adding a zero to integers with a preceding dot when the change will result in a valid floating point literal.

For example, `.0x0` should not be turned into `0.0x0`.

r? nnethercote
2023-01-31 00:03:08 +00:00
Edward Shen
e905b93706
Make the "extra if in let...else block" hint a suggestion 2023-01-30 14:09:40 -08:00
Esteban Küber
449dfc64f0 Fix unquoted projection types in label 2023-01-30 22:02:30 +00:00
Esteban Küber
d86835769c Make structured suggestion for fn casting verbose 2023-01-30 21:55:25 +00:00
Esteban Küber
6c2c8edac3 Tweak E0271 wording 2023-01-30 21:51:35 +00:00
Esteban Küber
5ae8e23816 Mention fn coercion rules (needs to be expanded) 2023-01-30 21:51:33 +00:00
Cassaundra Smith
80fcd7c40e
Fix invalid float literal suggestions when recovering an integer
Only suggest adding a zero to integers with a preceding dot when the change will
result in a valid floating point literal.

For example, `.0x0` should not be turned into `0.0x0`.
2023-01-30 13:39:25 -08:00
Esteban Küber
153ed09fb3 Tweak use of trimmed paths 2023-01-30 20:12:21 +00:00
Esteban Küber
ab8dc9a0ad Hide lifetimes of impl Trait in force trimmed paths 2023-01-30 20:12:21 +00:00
Esteban Küber
252c43b42b Do not mention lifetime names in force trimmed paths 2023-01-30 20:12:21 +00:00
Esteban Küber
81973a39e0 Don't show for<'lt> in force trimmed paths 2023-01-30 20:12:21 +00:00
Esteban Küber
62ba3e70a1 Modify primary span label for E0308
The previous output was unintuitive to users.
2023-01-30 20:12:19 +00:00
Matthias Kaak
8d7b092a11
Improved wording of error messages of missing remainder implementations 2023-01-30 19:54:33 +00:00
Michael Goulet
c24844048f Trait upcasting support in new solver 2023-01-30 19:11:01 +00:00
Michael Goulet
085a48e798 Implement unsizing in the new trait solver 2023-01-30 19:11:01 +00:00
Michael Goulet
343a359109 Use ObligationCtxt::new_in_snapshot in satisfied_from_param_env 2023-01-30 19:04:59 +00:00
Lucille Blumire
8348f25493
Update bastion-of-the-turbofish.rs
The original tweet in the chain linked to, and thus the through line of links back to Anna's tweet where she named the turbofish (https://web.archive.org/web/20210911061514/https://twitter.com/whoisaldeka/status/914914008225816576) are lost as the user whoisaldeka has deleted their twitter account.

Switching to an archive link preserves this through line, allowing someone to browse back to see the point at which Anna created the turbofish, as was the original intent of including this context.
2023-01-30 14:22:41 +00:00
bors
fba9f33c7c Auto merge of #107463 - Dylan-DPC:rollup-6mq1li8, r=Dylan-DPC
Rollup of 6 pull requests

Successful merges:

 - #101569 (Don't re-export private/unstable ArgumentV1 from `alloc`.)
 - #106106 (Pass `branch.{branch}.remote=origin` to `git submodule update`)
 - #107146 (Make `unsizing_params_for_adt` into a query)
 - #107264 (Add option to include private items in library docs)
 - #107452 (Fix typo in `{Rc, Arc}::get_mut_unchecked` docs)
 - #107459 (end entry paragraph with a period (.))

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2023-01-30 11:14:21 +00:00
Dylan DPC
28340bab88
Rollup merge of #101569 - m-ou-se:alloc-no-rexport-argumentv1, r=thomcc
Don't re-export private/unstable ArgumentV1 from `alloc`.

The `alloc::fmt::ArgumentV1` re-export was marked as `#[stable]` even though the original `core::fmt::ArgumentV1` is `#[unstable]` (and `#[doc(hidden)]`).

(It wasn't usable though:

```
error[E0658]: use of unstable library feature 'fmt_internals': internal to format_args!
 --> src/main.rs:4:12
  |
4 |     let _: alloc::fmt::ArgumentV1 = todo!();
  |            ^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: add `#![feature(fmt_internals)]` to the crate attributes to enable
```
)

Part of #99012
2023-01-30 15:11:44 +05:30
bors
3f25e56496 Auto merge of #104429 - nnethercote:more-deriving-on-packed-structs, r=RalfJung
More deriving on packed structs

See [here](https://github.com/rust-lang/rust/pull/104429#issuecomment-1320909245) for the t-lang nomination summary, and [here](https://github.com/rust-lang/rust/pull/104429#issuecomment-1360077895) for the approval.

r? `@RalfJung`
2023-01-30 07:02:01 +00:00
Nicholas Nethercote
2e93f2c92f Allow more deriving on packed structs.
Currently, deriving on packed structs has some non-trivial limitations,
related to the fact that taking references on unaligned fields is UB.

The current approach to field accesses in derived code:
- Normal case: `&self.0`
- In a packed struct that derives `Copy`: `&{self.0}`
- In a packed struct that doesn't derive `Copy`: `&self.0`

Plus, we disallow deriving any builtin traits other than `Default` for any
packed generic type, because it's possible that there might be
misaligned fields. This is a fairly broad restriction.

Plus, we disallow deriving any builtin traits other than `Default` for most
packed types that don't derive `Copy`. (The exceptions are those where the
alignments inherently satisfy the packing, e.g. in a type with
`repr(packed(N))` where all the fields have alignments of `N` or less
anyway. Such types are pretty strange, because the `packed` attribute is
not having any effect.)

This commit introduces a new, simpler approach to field accesses:
- Normal case: `&self.0`
- In a packed struct: `&{self.0}`

In the latter case, this requires that all fields impl `Copy`, which is
a new restriction. This means that the following example compiles under
the old approach and doesn't compile under the new approach.
```
 #[derive(Debug)]
 struct NonCopy(u8);

 #[derive(Debug)
 #[repr(packed)]
 struct MyType(NonCopy);
```
(Note that the old approach's support for cases like this was brittle.
Changing the `u8` to a `u16` would be enough to stop it working. So not
much capability is lost here.)

However, the other constraints from the old rules are removed. We can now
derive builtin traits for packed generic structs like this:
```
 trait Trait { type A; }

 #[derive(Hash)]
 #[repr(packed)]
 pub struct Foo<T: Trait>(T, T::A);
```
To allow this, we add a `T: Copy` bound in the derived impl and a `T::A:
Copy` bound in where clauses. So `T` and `T::A` must impl `Copy`.

We can now also derive builtin traits for packed structs that don't derive
`Copy`, so long as the fields impl `Copy`:
```
 #[derive(Hash)]
 #[repr(packed)]
 pub struct Foo(u32);
```
This includes types that hand-impl `Copy` rather than deriving it, such as the
following, that show up in winapi-0.2:
```
 #[derive(Clone)]
 #[repr(packed)]
 struct MyType(i32);

 impl Copy for MyType {}
```
The new approach is simpler to understand and implement, and it avoids
the need for the `unsafe_derive_on_repr_packed` check.

One exception is required for backwards-compatibility: we allow `[u8]`
fields for now. There is a new lint for this,
`byte_slice_in_packed_struct_with_derive`.
2023-01-30 12:00:42 +11:00
Mara Bos
47adb652d3 Update tests. 2023-01-29 20:19:26 +01:00
Matthias Krüger
45446824e3
Rollup merge of #107006 - b-naber:thir-tree, r=jackh726
Output tree representation on thir-tree

The current output of `-Zunpretty=thir-tree` is really cumbersome to work with, using an actual tree representation should make it easier to see what the thir looks like.
2023-01-29 20:03:37 +01:00
Matthias Krüger
8691602151
Rollup merge of #106540 - lowr:patch/remove-paren-whitespace, r=cjgillot
Insert whitespace to avoid ident concatenation in suggestion

This PR tweaks the suggestion of removing misplaced parentheses around trait bounds so as to avoid concatenating two identifiers. Although subtle, this should make outputs less surprising especially when applying the `MachineApplicable` suggestions automatically.
2023-01-29 20:03:35 +01:00
Ryo Yoshida
807ebac887
Insert whitespace to avoid ident concatenation in suggestion 2023-01-29 21:01:35 +09:00
bors
d117135f5a Auto merge of #106253 - nbdd0121:upcast, r=compiler-errors
Skip possible where_clause_object_safety lints when checking `multiple_supertrait_upcastable`

Fix #106247

To achieve this, I lifted the `WhereClauseReferencesSelf` out from `object_safety_violations` and move it into `is_object_safe` (which is changed to a new query).

cc `@dtolnay`
r? `@compiler-errors`
2023-01-29 10:20:25 +00:00
bors
a29efccb1e Auto merge of #107435 - matthiaskrgr:rollup-if5h6yu, r=matthiaskrgr
Rollup of 8 pull requests

Successful merges:

 - #106618 (Disable `linux_ext` in wasm32 and fortanix rustdoc builds.)
 - #107097 (Fix def-use dominance check)
 - #107154 (library/std/sys_common: Define MIN_ALIGN for m68k-unknown-linux-gnu)
 - #107397 (Gracefully exit if --keep-stage flag is used on a clean source tree)
 - #107401 (remove the usize field from CandidateSource::AliasBound)
 - #107413 (make more pleasant to read)
 - #107422 (Also erase substs for new infcx in pin move error)
 - #107425 (Check for missing space between fat arrow and range pattern)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2023-01-29 07:01:58 +00:00
Matthias Krüger
4e8f7e4fc9
Rollup merge of #107425 - clubby789:match-range-missing-space, r=compiler-errors
Check for missing space between fat arrow and range pattern

Fixes #107420

Ideally we wouldn't emit an error about expecting `=>` etc., but I'm not sure how to recover from this.

`@rustbot` label +A-diagnostics
2023-01-29 06:14:20 +01:00
Matthias Krüger
5ff6cdca7e
Rollup merge of #107422 - Nilstrieb:erase-the-ice, r=compiler-errors
Also erase substs for new infcx in pin move error

The code originally correctly erased the regions of the type it passed to the newly created infcx. But after the `fn_sig` query was made to return an `EarlyBinder<T>`, some substs that were around were substituted there without erasing their regions. They were then passed into the newly cerated infcx, which caused the ICE.

Fixes #107419

r? compiler-errors who reviewed the original PR adding this diagnostic
2023-01-29 06:14:20 +01:00
Matthias Krüger
4caa9dfa71
Rollup merge of #107097 - tmiasko:ssa, r=cjgillot
Fix def-use dominance check

A definition does not dominate a use in the same statement. For example
in MIR generated for compound assignment x += a (when overflow checks
are disabled).
2023-01-29 06:14:17 +01:00
bors
3cdd0197e7 Auto merge of #106227 - bryangarza:ctfe-limit, r=oli-obk
Use stable metric for const eval limit instead of current terminator-based logic

This patch adds a `MirPass` that inserts a new MIR instruction `ConstEvalCounter` to any loops and function calls in the CFG. This instruction is used during Const Eval to count against the `const_eval_limit`, and emit the `StepLimitReached` error, replacing the current logic which uses Terminators only.

The new method of counting loops and function calls should be more stable across compiler versions (i.e., not cause crates that compiled successfully before, to no longer compile when changes to the MIR generation/optimization are made).

Also see: #103877
2023-01-29 04:11:27 +00:00
bors
9f82651a5f Auto merge of #103659 - clubby789:improve-partialord-derive, r=nagisa
Special-case deriving `PartialOrd` for enums with dataless variants

I was able to get slightly better codegen by flipping the derived `PartialOrd` logic for two-variant enums.  I also tried to document the implementation of the derive macro to make the special-case logic a little clearer.
```rs
#[derive(PartialEq, PartialOrd)]
pub enum A<T> {
    A,
    B(T)
}
```
```diff
impl<T: ::core::cmp::PartialOrd> ::core::cmp::PartialOrd for A<T> {
   #[inline]
   fn partial_cmp(
       &self,
       other: &A<T>,
   ) -> ::core::option::Option<::core::cmp::Ordering> {
       let __self_tag = ::core::intrinsics::discriminant_value(self);
       let __arg1_tag = ::core::intrinsics::discriminant_value(other);
-      match ::core::cmp::PartialOrd::partial_cmp(&__self_tag, &__arg1_tag) {
-          ::core::option::Option::Some(::core::cmp::Ordering::Equal) => {
-              match (self, other) {
-                  (A::B(__self_0), A::B(__arg1_0)) => {
-                      ::core::cmp::PartialOrd::partial_cmp(__self_0, __arg1_0)
-                  }
-                  _ => ::core::option::Option::Some(::core::cmp::Ordering::Equal),
-              }
+      match (self, other) {
+          (A::B(__self_0), A::B(__arg1_0)) => {
+              ::core::cmp::PartialOrd::partial_cmp(__self_0, __arg1_0)
           }
-          cmp => cmp,
+          _ => ::core::cmp::PartialOrd::partial_cmp(&__self_tag, &__arg1_tag),
       }
   }
}
```
Godbolt: [Current](https://godbolt.org/z/GYjEzG1T8), [New](https://godbolt.org/z/GoK78qx15)
I'm not sure how common a case comparing two enums like this (such as `Option`) is, and if it's worth the slowdown of adding a special case to the derive. If it causes overall regressions it might be worth just manually implementing this for `Option`.
2023-01-28 22:11:11 +00:00
clubby789
4bfab39f9b Check for missing space between fat arrow and range pattern 2023-01-28 20:52:01 +00:00
Nilstrieb
832751fe1d Also erase substs for new infcx in pin move error
The code originally correctly erased the regions of the type it passed
to the newly created infcx. But after the `fn_sig` query was made to
return an `EarlyBinder<T>`, some substs that were around were
substituted there without erasing their regions. They were then passed
into the newly cerated infcx, which caused the ICE.
2023-01-28 20:43:16 +01:00
Gary Guo
66f3ab90a1 Reintroduce multiple_supertrait_upcastable lint 2023-01-28 15:08:07 +00:00