bors [Wed, 16 Jun 2021 07:20:27 +0000 (07:20 +0000)]
Auto merge of #86291 - crlf0710:trait_vtbl_refactor, r=bjorn3
Refactor vtable codegen
This refactor the codegen of vtables of miri interpreter, llvm, cranelift codegen backends.
This is preparation for the implementation of trait upcasting feature. cc #65991
Note that aside from code reorganization, there's an internal behavior change here that now InstanceDef::Virtual's index now include the three metadata slots, and now the first method is with index 3.
bors [Wed, 16 Jun 2021 04:51:54 +0000 (04:51 +0000)]
Auto merge of #86348 - JohnTitor:rollup-o6a6k67, r=JohnTitor
Rollup of 8 pull requests
Successful merges:
- #85283 (Avoid possible filename collision in coverage tests)
- #86200 (Updates `Clone` docs for `Copy` comparison.)
- #86209 (fix minor wording/typo issues in core::option docs)
- #86242 (rustdoc- dont ICE on `ConstEvaluatable` predicates)
- #86280 (Add a regression test for issue-76510)
- #86293 (Allow to run only a few GUI tests)
- #86327 (Don't mark "safe" intrinsics as unsafe)
- #86345 (Remove some duplicate `char` assoc items on RELEASES.md)
Yuki Okushi [Wed, 16 Jun 2021 04:31:13 +0000 (13:31 +0900)]
Rollup merge of #86345 - JohnTitor:dup-char-items-in-relnotes, r=Mark-Simulacrum
Remove some duplicate `char` assoc items on RELEASES.md
They were stabilized on 1.52 but 1.53's note also has them mistakenly.
Originally reported on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/241545-t-release/topic/incorrect.20relnotes).
Yuki Okushi [Wed, 16 Jun 2021 04:31:08 +0000 (13:31 +0900)]
Rollup merge of #86242 - BoxyUwU:rustdoc-const-evaluatable-ice, r=oli-obk
rustdoc- dont ICE on `ConstEvaluatable` predicates
Fixes #77647
rustdoc doesn't need to be handling these as you cant write them, they just get added implicitly when you write a where clause containing an expression.
Yuki Okushi [Wed, 16 Jun 2021 04:31:06 +0000 (13:31 +0900)]
Rollup merge of #86200 - qwerty01:clone-doc-update, r=JohnTitor
Updates `Clone` docs for `Copy` comparison.
Quite a few people (myself included) have come under the impression that the difference between `Copy` and `Clone` is that `Copy` is cheap and `Clone` is expensive, where the actual difference is that `Copy` constrains the type to bit-wise copying, and `Clone` allows for more expensive operations. The source of this misconception is in the `Clone` docs, where the following line is in the description:
> Differs from `Copy` in that `Copy` is implicit and extremely inexpensive, while `Clone` is always explicit and may or may not be expensive.
The `Clone` documentation page also comes up before the `Copy` page on google when searching for "the difference between `Clone` and `Copy`".
This PR updates the documentation to clarify that "extremely inexpensive" means an "inexpensive bit-wise copy" to hopefully prevent future rust users from falling into this misunderstanding.
Yuki Okushi [Wed, 16 Jun 2021 04:31:04 +0000 (13:31 +0900)]
Rollup merge of #85283 - Swatinem:ordered-profraw, r=tmandry
Avoid possible filename collision in coverage tests
Previously, coverage tests were writing profiler data to files based on
their pid. As rustdoc spawns each doctest as its own process, it might
be possible in rare cases that a pid is being reused which would cause
a file to be overwritten, leading to incorrect coverage results.
bors [Wed, 16 Jun 2021 01:46:08 +0000 (01:46 +0000)]
Auto merge of #85820 - CDirkx:is_unicast_site_local, r=joshtriplett
Remove `Ipv6Addr::is_unicast_site_local`
Removes the unstable method `Ipv6Addr::is_unicast_site_local`, see also #85604 where I have tried to summarize related discussion so far.
Unicast site-local addresses (`fec0::/10`) were deprecated in [IETF RFC #3879](https://datatracker.ietf.org/doc/html/rfc3879), see also [RFC #4291 Section 2.5.7](https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.7). Any new implementation must no longer support the special behaviour of site-local addresses. This is mentioned in the docs of `is_unicast_site_local` and already implemented in `is_unicast_global`, which considers addresses in `fec0::/10` to have global scope, thus overlapping with `is_unicast_site_local`.
Given that RFC #3879 was published in 2004, long before Rust existed, and it is specified that any new implementation must no longer support the special behaviour of site-local addresses, I don't see how a user would ever have a need for `is_unicast_site_local`. It is also confusing that currently both `is_unicast_site_local` and `is_unicast_global` can be `true` for an address, but an address can actually only have a single scope. The deprecating RFC mentions that Site-Local scope was confusing to work with and that the classification of an address as either Link-Local or Global better matches the mental model of users.
There has been earlier discussion of removing `is_unicast_site_local` (https://github.com/rust-lang/rust/pull/60145#issuecomment-485970669) which decided against it, but that had the incorrect assumption that the method was already stable; it is not. (This confusion arose from the placement of the unstable attribute on the entire module, instead of on individual methods, resolved in #85672)
r? `@joshtriplett` as reviewer of all the related PRs
bors [Tue, 15 Jun 2021 22:56:41 +0000 (22:56 +0000)]
Auto merge of #85406 - VillSnow:integrate_binary_search, r=JohnTitor
Integrate binary search codes of binary_search_by and partition_point
For now partition_point has own binary search code piece.
It is because binary_search_by had called the comparer more times and the author (=me) wanted to avoid it.
However, now binary_search_by uses the comparer minimum times. (#74024)
So it's time to integrate them.
The appearance of the codes are a bit different but both use completely same logic.
Yuki Okushi [Tue, 15 Jun 2021 08:40:14 +0000 (17:40 +0900)]
Rollup merge of #86294 - m-ou-se:edition-prelude-modules, r=joshtriplett
Stabilize {std, core}::prelude::rust_*.
This stabilizes the `{core, std}::prelude::{rust_2015, rust_2018, rust_2021}` modules.
The usage of these modules as the prelude in those editions was already stabilized. This just stabilizes the modules themselves, making it possible for a user to explicitly refer to them.
Yuki Okushi [Tue, 15 Jun 2021 08:40:12 +0000 (17:40 +0900)]
Rollup merge of #86277 - jsha:remove-must-use, r=Manishearth
Remove must_use from ALLOWED_ATTRIBUTES
This is a fairly common attribute on methods, but is not something you need to know when reading the method docs - the purpose of the attribute is for the compiler to tell you about it if you forget to use a value.
Removing reclaims some valuable space in the summary of methods, particularly when the attribute has a long string value.
As discussed in #84309. Partially addresses #81482.
Yuki Okushi [Tue, 15 Jun 2021 08:40:08 +0000 (17:40 +0900)]
Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics, r=m-ou-se
Stabilize `ops::ControlFlow` (just the type)
Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR).
With the new `?` desugar implemented, [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR, godbolt was still on the 2021-05-01 nightly, where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of, so I'd like to propose that `ControlFlow` be considered for stabilization.
Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058, where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594), and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589, https://github.com/jonhoo/rust-imap/issues/194).
As this will need an FCP, picking a libs member manually:
r? `@m-ou-se`
## Stabilized APIs
```rust
#[derive(Debug, Clone, Copy, PartialEq)]
pub enum ControlFlow<B, C = ()> {
/// Exit the operation without running subsequent phases.
Break(B),
/// Move on to the next phase of the operation as normal.
Continue(C),
}
```
As well as using `?` on a `ControlFlow<B, _>` in a function returning `ControlFlow<B, _>`. (Note, in particular, that there's no `From::from`-conversion on the `Break` value, the way there is for `Err`s.)
## Existing APIs *not* stabilized here
All the associated methods and constants: `break_value`, `is_continue`, `map_break`, [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE), etc.
Some of the existing methods in nightly seem reasonable, some seem like they should be removed, and some need more discussion to decide. But none of them are *essential*, so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow), they're all omitted from this PR.
They can be considered separately later, as further usage demonstrates which are important.
Yuki Okushi [Tue, 15 Jun 2021 08:39:58 +0000 (17:39 +0900)]
Rollup merge of #80269 - pickfire:patch-4, r=joshtriplett
Explain non-dropped sender recv in docs
Original senders that are still hanging around could cause
Receiver::recv to not block since this is a potential footgun
for beginners, clarify more on this in the docs for readers to
be aware about it.
Maybe it would be better to show an example of the pattern where `drop(tx)` is used when it is being cloned multiple times? Although I have seen it in quite a few articles but I am surprised that this part is not very clear with the current words without careful reading.
> If the corresponding Sender has disconnected, or it disconnects while this call is blocking, this call will wake up and return Err to indicate that no more messages can ever be received on this channel. However, since channels are buffered, messages sent before the disconnect will still be properly received.
Some words there may seemed similar if I carefully read and relate it but if I am new, I probably does not know "drop" makes it "disconnected". So I mention the words "drop" and "alive" to make it more relatable to lifetime.
bors [Tue, 15 Jun 2021 00:13:53 +0000 (00:13 +0000)]
Auto merge of #84867 - pnkfelix:rustdoc-revert-deref-recur, r=jyn514
rustdoc: revert deref recur to resume inclusion of impl ExtTrait<Local> for ExtType
As discussed here: https://github.com/rust-lang/rust/issues/82465#issuecomment-829290384, Revert PR #80653 to resolve issue #82465.
Issue #82465 was we had stopped including certain trait implementations, namely implementations on an imported type of an imported trait *instantiated on a local type*. That bug was injected by PR #80653.
Reverting #80653 means we don't list all the methods that you have accessible via recursively applying `Deref`.
[Discussion in last week's rustc triage meeting](https://zulip-archive.rust-lang.org/238009tcompilermeetings/19557weekly2021042954818.html#236680594) led us to conclude that the bug was worse than the enhancement, and there was not an obvious fix for the bug itself. So for the short term we remove the enhancement, while in the long term we will work on figuring out a way to have our imported trait implementation cake and eat it too.
bors [Mon, 14 Jun 2021 20:17:02 +0000 (20:17 +0000)]
Auto merge of #86275 - lqd:ctfe-validation, r=RalfJung
Improve CTFE UB validation error messages
As mentioned in https://github.com/rust-lang/rust/pull/86245#discussion_r650494012 this PR slightly improves the formatting of validation errors, to move the path to the error prefix.
From:
`type validation failed: encountered invalid vtable: size is bigger than largest supported object at .0`
To:
`type validation failed at .0: encountered invalid vtable: size is bigger than largest supported object`.
Arpad Borsos [Fri, 14 May 2021 09:04:48 +0000 (11:04 +0200)]
Avoid possible filename collision in coverage tests
Previously, coverage tests were writing profiler data to files based on
their pid. As rustdoc spawns each doctest as its own process, it might
be possible in rare cases that a pid is being reused which would cause
a file to be overwritten, leading to incorrect coverage results.
bors [Mon, 14 Jun 2021 17:21:28 +0000 (17:21 +0000)]
Auto merge of #86117 - ehuss:force-warns-underscore, r=rylev
Fix force-warns to allow dashes.
The `--force-warns` flag was not allowing lint names with dashes, only supporting underscores. This changes it to allow dashes to match the behavior of the A/W/D/F flags.
bors [Mon, 14 Jun 2021 13:05:54 +0000 (13:05 +0000)]
Auto merge of #86273 - JohnTitor:stabilize-maybe-uninit-ref, r=RalfJung
Stabilize `maybe_uninit_ref`
This stabilizes `assume_init_{ref,mut}`. FCP is complete: https://github.com/rust-lang/rust/issues/63568#issuecomment-590121300
The renaming was done by #76047 and FIXME was resolved by #76241, so I think we can now stabilize them finally 🎉
Still, it's const-unstable as `assert_inhabited` is unstable.
bors [Mon, 14 Jun 2021 10:24:48 +0000 (10:24 +0000)]
Auto merge of #85758 - petertodd:2021-revert-manuallydrop-clone-from, r=m-ou-se
Revert #85176 addition of `clone_from` for `ManuallyDrop`
Forwarding `clone_from` to the inner value changes the observable behavior, as previously the inner value would *not* be dropped by the default implementation.
Frankly, this is a super-niche case, so #85176 is welcome to argue the behavior should be otherwise! But if we overrride it, IMO documenting the behavior would be good.
This is a fairly common attribute on methods, but is not something you
need to know when reading the method docs - the purpose of the attribute
is for the compiler to tell you about it if you forget to use a value.
Removing reclaims some valuable space in the summary of methods.
bors [Sun, 13 Jun 2021 12:08:59 +0000 (12:08 +0000)]
Auto merge of #86245 - lqd:const-ub-align, r=RalfJung
Fix ICEs on invalid vtable size/alignment const UB errors
The invalid vtable size/alignment errors from `InterpCx::read_size_and_align_from_vtable` were "freeform const UB errors", causing ICEs when reaching validation. This PR turns them into const UB hard errors to catch them during validation and avoid that.
Fixes #86193
r? `@RalfJung`
(It seemed cleaner to have 2 variants but they can be merged into one variant with a message payload if you prefer that ?)
bors [Sun, 13 Jun 2021 01:27:37 +0000 (01:27 +0000)]
Auto merge of #86233 - JohnTitor:stabilize-simd-x86-bittest, r=Amanieu
Stabilize `simd_x86_bittest` feature
This pulls https://github.com/rust-lang/stdarch/pull/1180, FCP is complete: https://github.com/rust-lang/rust/issues/59414#issuecomment-826072554
Closes #59414
bors [Sat, 12 Jun 2021 23:08:16 +0000 (23:08 +0000)]
Auto merge of #86207 - ehuss:update-cargo, r=ehuss
Update cargo
11 commits in aa8b09297bb3156b849e73db48af4cd050492fe6..44456677b5d1d82fe981c955dc5c67734b31f340
2021-06-09 00:28:53 +0000 to 2021-06-12 18:00:01 +0000
- Fix package_default_run test. (rust-lang/cargo#9577)
- Change how the fix_deny_warnings_but_not_others test works (rust-lang/cargo#9571)
- Add mising documentation regarding `cargo doc` (rust-lang/cargo#9565)
- Implement warning for ignored trailing arguments (rust-lang/cargo#9561)
- Make clippy happy (rust-lang/cargo#9569)
- Fix rustc/rustdoc config values to be config-relative. (rust-lang/cargo#9566)
- Update rustfix. (rust-lang/cargo#9567)
- Warn if an "all" target is specified, but we don't match anything (rust-lang/cargo#9549)
- add default_run to SerializedPackage (rust-lang/cargo#9550)
- respect user choice of lib/bin over heuristics (rust-lang/cargo#9522)
- Add a mean to mutably access the members of a workspace (rust-lang/cargo#9547)
bors [Sat, 12 Jun 2021 15:29:51 +0000 (15:29 +0000)]
Auto merge of #82703 - iago-lito:nonzero_add_mul_pow, r=m-ou-se
Implement nonzero arithmetics for NonZero types.
Hello'all, this is my first PR to this repo.
Non-zero natural numbers are stable by addition/multiplication/exponentiation, so it makes sense to make this arithmetic possible with `NonZeroU*`.
The major pitfall is that overflowing underlying `u*` types possibly lead to underlying `0` values, which break the major invariant of `NonZeroU*`. To accommodate it, only `checked_` and `saturating_` operations are implemented.
Other variants allowing wrapped results like `wrapping_` or `overflowing_` are ruled out *de facto*.
`impl Add<u*> for NonZeroU* { .. }` was considered, as it panics on overflow which enforces the invariant, but it does not so in release mode. I considered forcing `NonZeroU*::add` to panic in release mode by deferring the check to `u*::checked_add`, but this is less explicit for the user than directly using `NonZeroU*::checked_add`.
Following `@Lokathor's` advice on zulip, I have dropped the idea.
`@poliorcetics` on Discord also suggested implementing `_sub` operations, but I'd postpone this to another PR if there is a need for it. My opinion is that it could be useful in some cases, but that it makes less sense because non-null natural numbers are not stable by subtraction even in theory, while the overflowing problem is just about technical implementation.
One thing I don't like is that the type of the `other` arg differs in every implementation: `_add` methods accept any raw positive integer, `_mul` methods only accept non-zero values otherwise the invariant is also broken, and `_pow` only seems to accept `u32` for a reason I ignore but that seems consistent throughout `std`. Maybe there is a better way to harmonize this?
This is it, Iope I haven't forgotten anything and I'll be happy to read your feedback.
bors [Sat, 12 Jun 2021 11:12:16 +0000 (11:12 +0000)]
Auto merge of #86215 - FabianWolff:unnameable-types, r=jackh726
Do not suggest to add type annotations for unnameable types
Consider this example:
```rust
const A = || 42;
struct S<T> { t: T }
const B: _ = S { t: || 42 };
```
This currently produces the following output:
```
error: missing type for `const` item
--> src/lib.rs:1:7
|
1 | const A = || 42;
| ^ help: provide a type for the item: `A: [closure@src/lib.rs:1:11: 1:16]`
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> src/lib.rs:4:10
|
4 | const B: _ = S { t: || 42 };
| ^
| |
| not allowed in type signatures
| help: replace `_` with the correct type: `S<[closure@src/lib.rs:4:21: 4:26]>`
error: aborting due to 2 previous errors
```
However, these suggestions are obviously useless, because the suggested types cannot be written down. With my changes, the suggestion is replaced with a note, because there is no simple fix:
```
error: missing type for `const` item
--> test.rs:1:7
|
1 | const A = || 42;
| ^
|
note: however, the inferred type `[closure@test.rs:1:11: 1:16]` cannot be named
--> test.rs:1:11
|
1 | const A = || 42;
| ^^^^^
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> test.rs:4:10
|
4 | const B: _ = S { t: || 42 };
| ^ not allowed in type signatures
|
note: however, the inferred type `S<[closure@test.rs:4:21: 4:26]>` cannot be named
--> test.rs:4:14
|
4 | const B: _ = S { t: || 42 };
| ^^^^^^^^^^^^^^
Ivan Tham [Mon, 21 Dec 2020 18:16:01 +0000 (02:16 +0800)]
Explain non-dropped sender recv in docs
Original senders that are still hanging around could cause
Receiver::recv to not block since this is a potential footgun
for beginners, clarify more on this in the docs for readers to
be aware about it.
Fix minor tidbits in sender recv doc
Co-authored-by: Dylan DPC <dylan.dpc@gmail.com>
Add example for unbounded receive loops in doc
Show the drop(tx) pattern, based on tokio docs
https://tokio-rs.github.io/tokio/doc/tokio/sync/index.html
bors [Sat, 12 Jun 2021 01:21:56 +0000 (01:21 +0000)]
Auto merge of #86226 - JohnTitor:rollup-5ubdolf, r=JohnTitor
Rollup of 7 pull requests
Successful merges:
- #85800 (Fix some diagnostic issues with const_generics_defaults feature gate)
- #85823 (Do not suggest ampmut if rhs is already mutable)
- #86153 (Print dummy spans as `no-location`)
- #86174 (Detect incorrect vtable alignment during const eval)
- #86189 (Make `relate_type_and_mut` public)
- #86205 (Run full const-generics test for issue-72293)
- #86217 (Remove "generic type" in boxed.rs)
Yuki Okushi [Fri, 11 Jun 2021 16:16:01 +0000 (01:16 +0900)]
Rollup merge of #86189 - JohnTitor:relate-fn-pub, r=Aaron1011
Make `relate_type_and_mut` public
#85343 improved diagnostics around `Relate` impls but made `relate_type_and_mut` private, which was accessible as `relate` previously. This makes it public so that we can use it on rust-semverver.
Yuki Okushi [Fri, 11 Jun 2021 16:16:00 +0000 (01:16 +0900)]
Rollup merge of #86174 - lqd:const-ub-align, r=RalfJung
Detect incorrect vtable alignment during const eval
This PR fixes #86132 by detecting invalid alignment values for trait objects in the interpreter, and emitting an error about this conversion failure, to avoid the ICE.
I've noticed that the error emitted at https://github.com/rust-lang/rust/blob/a50d72158e08e02cfc051b863017bdbd2c45b637/compiler/rustc_mir/src/interpret/traits.rs#L163-L166 doesn't seem to be present in the const-ub tests, so I've tried adding a test that triggers both of these cases: one for the invalid size, and another for the invalid alignment that #86132 tracks (I have found different magic values triggering different `Align::from_bytes` errors than the "power of 2" one, if need be).
However, when doing that, I *cannot* for the life of me figure out the correct incantation to make these 2 errors trigger with the "it is undefined behavior to use this value" message rather than the "any use of this value will cause an error" lint.
I've tried Oli's suggestions of different values, tuples and arrays, using the transparent wrapper trick from the other tests and I was only able to trigger the regular const-ub errors about the size of the vtable, or that the drop pointer was invalid. Maybe these "type validation failed" errors happen before this part of the interpreter is reached and there just needs some magic incorrect values to bypass them, I don't know.
Since this fixes an ICE, and if the constants are indeed used, these 2 tests will turn into a hard error, I thought I'd open the PR anyways. And if ```@RalfJung``` you know of a way I could manage that (if you think that these tests are worth checking that the `throw_ub_format!` does indeed create const-ub errors as we expect) I'd be grateful.
For that reason, r? ```@RalfJung``` and cc ```@oli-obk.```
Yuki Okushi [Fri, 11 Jun 2021 16:15:57 +0000 (01:15 +0900)]
Rollup merge of #85823 - fee1-dead:borrowck-0, r=jackh726
Do not suggest ampmut if rhs is already mutable
Removes invalid suggestion in #85765, although it should highlight the user type instead of the local variable.
Looking at the comments of this line:
https://github.com/rust-lang/rust/blob/84b1005bfd22e2cb2a4c13b0b81958fe72628354/compiler/rustc_mir_build/src/build/matches/mod.rs#L2107
It was intentionally set to `None`, causing it to highlight the local variable instead. I am not sure if I will be able to fix it.
Yuki Okushi [Fri, 11 Jun 2021 16:15:56 +0000 (01:15 +0900)]
Rollup merge of #85800 - BoxyUwU:const-param-default-diagnostics, r=oli-obk
Fix some diagnostic issues with const_generics_defaults feature gate
This PR makes a few changes:
- print out const param defaults in "lifetime ordering" errors rather than discarding them
- update `is_simple_text` to account for const params when checking if a type has no generics, this was causing a note to be failed to add to an error message
- fixes some diagnostic wording that incorrectly said there was ordering restrictions between type/const params despite the `const_generics_defaults` feature gate is active
bors [Fri, 11 Jun 2021 10:25:53 +0000 (10:25 +0000)]
Auto merge of #86116 - FabianWolff:issue-86100, r=varkor
Suggest a trailing comma if a 1-tuple is expected and a parenthesized expression is found
This pull request fixes #86100. The following code:
```rust
fn main() {
let t: (i32,) = (1);
}
```
currently produces:
```
warning: unnecessary parentheses around assigned value
--> test.rs:2:21
|
2 | let t: (i32,) = (1);
| ^^^ help: remove these parentheses
|
= note: `#[warn(unused_parens)]` on by default
error[E0308]: mismatched types
--> test.rs:2:21
|
2 | let t: (i32,) = (1);
| ------ ^^^ expected tuple, found integer
| |
| expected due to this
|
= note: expected tuple `(i32,)`
found type `{integer}`
error: aborting due to previous error; 1 warning emitted
```
With my changes, I get the same warning and the following error:
```
error[E0308]: mismatched types
--> test.rs:2:21
|
2 | let t: (i32,) = (1);
| ------ ^^^ expected tuple, found integer
| |
| expected due to this
|
= note: expected tuple `(i32,)`
found type `{integer}`
help: use a trailing comma to create a tuple with one element
|
2 | let t: (i32,) = (1,);
| ^^^^
```
i.e. I have added a suggestion to add a trailing comma to create a 1-tuple. This suggestion is only issued if a 1-tuple is expected and the expression (`(1)` in the example above) is surrounded by parentheses and does not already have a tuple type. In this situation, I'd say that it is pretty likely that the user meant to create a tuple.
projects / rust.git / log