Commit Graph

261133 Commits

Author SHA1 Message Date
Esteban Küber
3ff758877f More accurate suggestion for -> Box<dyn Trait> or -> impl Trait
When encountering `-> Trait`, suggest `-> Box<dyn Trait>` (instead of `-> Box<Trait>`.

If there's a single returned type within the `fn`, suggest `-> impl Trait`.
2024-07-19 19:39:37 +00:00
bors
3811f40d27 Auto merge of #127957 - matthiaskrgr:rollup-1u5ivck, r=matthiaskrgr
Rollup of 6 pull requests

Successful merges:

 - #127350 (Parser: Suggest Placing the Return Type After Function Parameters)
 - #127621 (Rewrite and rename `issue-22131` and `issue-26006` `run-make` tests to rmake)
 - #127662 (When finding item gated behind a `cfg` flag, point at it)
 - #127903 (`force_collect` improvements)
 - #127932 (rustdoc: fix `current` class on sidebar modnav)
 - #127943 (Don't allow unsafe statics outside of extern blocks)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-19 13:39:12 +00:00
bors
11e57241f1 Auto merge of #127956 - tgross35:rollup-8ten7pk, r=tgross35
Rollup of 7 pull requests

Successful merges:

 - #121533 (Handle .init_array link_section specially on wasm)
 - #127825 (Migrate `macos-fat-archive`, `manual-link` and `archive-duplicate-names` `run-make` tests to rmake)
 - #127891 (Tweak suggestions when using incorrect type of enum literal)
 - #127902 (`collect_tokens_trailing_token` cleanups)
 - #127928 (Migrate `lto-smoke-c` and `link-path-order` `run-make` tests to rmake)
 - #127935 (Change `binary_asm_labels` to only fire on x86 and x86_64)
 - #127953 ([compiletest] Search *.a when getting dynamic libraries on AIX)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-19 11:08:02 +00:00
Matthias Krüger
6fe68f88e7
Rollup merge of #127943 - compiler-errors:no-unsafe, r=spastorino
Don't allow unsafe statics outside of extern blocks

This PR fixes a regression where we allowed `unsafe static` items in top-level modules (i.e. outside of `unsafe extern` blocks).

It's harder IMO to integrate this into the `check_item_safety` function, so I opted to just put this check on the `static` item itself.

Beta version of this lives at #127944.

r? ```@oli-obk``` or ```@spastorino```
2024-07-19 10:48:06 +02:00
Matthias Krüger
1c665738de
Rollup merge of #127932 - notriddle:notriddle/current, r=GuillaumeGomez
rustdoc: fix `current` class on sidebar modnav

| Before | After |
| -- | -- |
| ![image](https://github.com/user-attachments/assets/35866be8-5a58-41eb-9169-b2bb403fe7cd) | ![image](https://github.com/user-attachments/assets/89b087ea-82bf-49f5-9c87-20162880eb32)
2024-07-19 10:48:06 +02:00
Matthias Krüger
9ada89d9a1
Rollup merge of #127903 - nnethercote:force_collect-improvements, r=petrochenkov
`force_collect` improvements

Yet more cleanups relating to `cfg_attr` processing.

r? ````@petrochenkov````
2024-07-19 10:48:05 +02:00
Matthias Krüger
98fdfcb11b
Rollup merge of #127662 - estebank:gate-span, r=TaKO8Ki
When finding item gated behind a `cfg` flag, point at it

Previously we would only mention that the item was gated out, and opportunisitically mention the feature flag name when possible. We now point to the place where the item was gated, which can be behind layers of macro indirection, or in different modules.

```
error[E0433]: failed to resolve: could not find `doesnt_exist` in `inner`
  --> $DIR/diagnostics-cross-crate.rs:18:23
   |
LL |     cfged_out::inner::doesnt_exist::hello();
   |                       ^^^^^^^^^^^^ could not find `doesnt_exist` in `inner`
   |
note: found an item that was configured out
  --> $DIR/auxiliary/cfged_out.rs:6:13
   |
LL |     pub mod doesnt_exist {
   |             ^^^^^^^^^^^^
note: the item is gated here
  --> $DIR/auxiliary/cfged_out.rs:5:5
   |
LL |     #[cfg(FALSE)]
   |     ^^^^^^^^^^^^^
```
2024-07-19 10:48:05 +02:00
Matthias Krüger
7161e2dc98
Rollup merge of #127621 - Oneirical:hypnotest-show, r=jieyouxu
Rewrite and rename `issue-22131` and `issue-26006` `run-make` tests to rmake

Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).

Please try:

try-job: x86_64-msvc
try-job: i686-mingw
2024-07-19 10:48:04 +02:00
Matthias Krüger
c86e13f330
Rollup merge of #127350 - veera-sivarajan:bugfix-126311, r=lcnr
Parser: Suggest Placing the Return Type After Function Parameters

Fixes #126311

This PR suggests placing the return type after the function parameters when it's misplaced after a `where` clause.

This also tangentially improves diagnostics for cases like [this](86d6f1312a/tests/ui/parser/issues/misplaced-return-type-without-where-issue-126311.rs (L1C1-L1C28)) and adds doc comments for `parser::AllowPlus`.
2024-07-19 10:48:03 +02:00
bors
8c3a94a1c7 Auto merge of #125915 - camelid:const-arg-refactor, r=BoxyUwU
Represent type-level consts with new-and-improved `hir::ConstArg`

### Summary

This is a step toward `min_generic_const_exprs`. We now represent all const
generic arguments using an enum that differentiates between const *paths*
(temporarily just bare const params) and arbitrary anon consts that may perform
computations. This will enable us to cleanly implement the `min_generic_const_args`
plan of allowing the use of generics in paths used as const args, while
disallowing their use in arbitrary anon consts. Here is a summary of the salient
aspects of this change:

- Add `current_def_id_parent` to `LoweringContext`

  This is needed to track anon const parents properly once we implement
  `ConstArgKind::Path` (which requires moving anon const def-creation
  outside of `DefCollector`).

- Create `hir::ConstArgKind` enum with `Path` and `Anon` variants. Use it in the
  existing `hir::ConstArg` struct, replacing the previous `hir::AnonConst` field.

- Use `ConstArg` for all instances of const args. Specifically, use it instead
  of `AnonConst` for assoc item constraints, array lengths, and const param
  defaults.

- Some `ast::AnonConst`s now have their `DefId`s created in
  rustc_ast_lowering rather than `DefCollector`. This is because in some
  cases they will end up becoming a `ConstArgKind::Path` instead, which
  has no `DefId`. We have to solve this in a hacky way where we guess
  whether the `AnonConst` could end up as a path const since we can't
  know for sure until after name resolution (`N` could refer to a free
  const or a nullary struct). If it has no chance as being a const
  param, then we create a `DefId` in `DefCollector` -- otherwise we
  decide during ast_lowering. This will have to be updated once all path
  consts use `ConstArgKind::Path`.

- We explicitly use `ConstArgHasType` for array lengths, rather than
  implicitly relying on anon const type feeding -- this is due to the
  addition of `ConstArgKind::Path`.

- Some tests have their outputs changed, but the changes are for the
  most part minor (including removing duplicate or almost-duplicate
  errors). One test now ICEs, but it is for an incomplete, unstable
  feature and is now tracked at https://github.com/rust-lang/rust/issues/127009.

### Followup items post-merge

- Use `ConstArgKind::Path` for all const paths, not just const params.
- Fix (no github dont close this issue) #127009
- If a path in generic args doesn't resolve as a type, try to resolve as a const
  instead (do this in rustc_resolve). Then remove the special-casing from
  `rustc_ast_lowering`, so that all params will automatically be lowered as
  `ConstArgKind::Path`.
- (?) Consider making `const_evaluatable_unchecked` a hard error, or at least
  trying it in crater

r? `@BoxyUwU`
2024-07-19 08:44:51 +00:00
Trevor Gross
314cf1fc7a
Rollup merge of #127953 - bzEq:aix-compiletest-dylib-suffix, r=jieyouxu
[compiletest] Search *.a when getting dynamic libraries on AIX

AIX uses `.a` as dylib suffix. Support it in compiletest.
2024-07-19 03:27:50 -05:00
Trevor Gross
6bdf9bd276
Rollup merge of #127935 - tgross35:binary_asm_labels-x86-only, r=estebank,Urgau
Change `binary_asm_labels` to only fire on x86 and x86_64

In <https://github.com/rust-lang/rust/pull/126922>, the `binary_asm_labels` lint was added which flags labels such as `0:` and `1:`. Before that change, LLVM was giving a confusing error on x86/x86_64 because of an incorrect interpretation.

However, targets other than x86 and x86_64 never had the error message and have not been a problem. This means that the lint was causing code that previously worked to start failing (e.g. `compiler_builtins`), rather than only providing a more clear messages where there has always been an error.

Adjust the lint to only fire on x86 and x86_64 assembly to avoid this regression.

Also update the help message.

Fixes: https://github.com/rust-lang/rust/issues/127821
2024-07-19 03:27:50 -05:00
Trevor Gross
0641b37747
Rollup merge of #127928 - Oneirical:anatesthetic-sleep, r=Kobzol
Migrate `lto-smoke-c` and `link-path-order` `run-make` tests to rmake

Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
2024-07-19 03:27:49 -05:00
Trevor Gross
41557426c5
Rollup merge of #127902 - nnethercote:collect_tokens_trailing_token-cleanups, r=petrochenkov
`collect_tokens_trailing_token` cleanups

More cleanups I made while understanding the code for processing `cfg_attr`, to fix test failures in #124141.

r? `@petrochenkov`
2024-07-19 03:27:48 -05:00
Trevor Gross
fc6e34f38f
Rollup merge of #127891 - estebank:enum-type-sugg, r=estebank
Tweak suggestions when using incorrect type of enum literal

More accurate suggestions when writing wrong style of enum variant literal:

```
error[E0533]: expected value, found struct variant `E::Empty3`
  --> $DIR/empty-struct-braces-expr.rs:18:14
   |
LL |     let e3 = E::Empty3;
   |              ^^^^^^^^^ not a value
   |
help: you might have meant to create a new value of the struct
   |
LL |     let e3 = E::Empty3 {};
   |                        ++
```
```
error[E0533]: expected value, found struct variant `E::V`
  --> $DIR/struct-literal-variant-in-if.rs:10:13
   |
LL |     if x == E::V { field } {}
   |             ^^^^ not a value
   |
help: you might have meant to create a new value of the struct
   |
LL |     if x == (E::V { field }) {}
   |             +              +
```
```
error[E0618]: expected function, found enum variant `Enum::Unit`
  --> $DIR/suggestion-highlights.rs:15:5
   |
LL |     Unit,
   |     ---- enum variant `Enum::Unit` defined here
...
LL |     Enum::Unit();
   |     ^^^^^^^^^^--
   |     |
   |     call expression requires function
   |
help: `Enum::Unit` is a unit enum variant, and does not take parentheses to be constructed
   |
LL -     Enum::Unit();
LL +     Enum::Unit;
   |
```
```
error[E0599]: no variant or associated item named `tuple` found for enum `Enum` in the current scope
  --> $DIR/suggestion-highlights.rs:36:11
   |
LL | enum Enum {
   | --------- variant or associated item `tuple` not found for this enum
...
LL |     Enum::tuple;
   |           ^^^^^ variant or associated item not found in `Enum`
   |
help: there is a variant with a similar name
   |
LL |     Enum::Tuple(/* i32 */);
   |           ~~~~~~~~~~~~~~~~;
   |
```

Tweak "field not found" suggestion when giving struct literal for tuple struct type:

```
error[E0560]: struct `S` has no field named `x`
  --> $DIR/nested-non-tuple-tuple-struct.rs:8:19
   |
LL | pub struct S(f32, f32);
   |            - `S` defined here
...
LL |     let _x = (S { x: 1.0, y: 2.0 }, S { x: 3.0, y: 4.0 });
   |                   ^ field does not exist
   |
help: `S` is a tuple struct, use the appropriate syntax
   |
LL |     let _x = (S(/* f32 */, /* f32 */), S { x: 3.0, y: 4.0 });
   |               ~~~~~~~~~~~~~~~~~~~~~~~
2024-07-19 03:27:48 -05:00
Trevor Gross
39ccb8a769
Rollup merge of #127825 - Oneirical:self-testeem, r=jieyouxu
Migrate `macos-fat-archive`, `manual-link` and `archive-duplicate-names` `run-make` tests to rmake

Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).

Please try:

try-job: x86_64-msvc
try-job: aarch64-apple
2024-07-19 03:27:47 -05:00
Trevor Gross
986d6bf9fb
Rollup merge of #121533 - ratmice:wasm_init_fini_array, r=nnethercote
Handle .init_array link_section specially on wasm

Given that wasm-ld now has support for [.init_array](8f2bd8ae68/llvm/lib/MC/WasmObjectWriter.cpp (L1852)), it appears we can easily implement that section by falling through to the normal path rather than taking the typical custom_section path for wasm.

The wasm-ld appears to have a bunch of limitations. Only one static with the `link_section` in a crate or else you hit the fatal error in the link above "only one .init_array section fragment supported". They do not get merged.

You can still call multiple constructors by setting it to an array.

```
unsafe extern "C" fn ctor() {
    println!("foo");
}
#[used]
#[link_section = ".init_array"]
static FOO: [unsafe extern "C" fn(); 2] = [ctor, ctor];
```

Another issue appears to be that if crate *A* depends on crate *B*, but *A* doesn't call any symbols from *B* and *B* doesn't `#[export_name = ...]` any symbols, then crate *B*'s constructor will not be called.  The workaround to this is to provide an exported symbol in crate *B*.
2024-07-19 03:27:46 -05:00
Trevor Gross
5686720a57 Update the binary_asm_label documentation
Disable a test that now only passes on x86 and make the link point to
the new (open) LLVM bug.
2024-07-19 01:21:15 -05:00
Nicholas Nethercote
1dd566a6d0 Overhaul comments in collect_tokens_trailing_token.
Adding details, clarifying lots of little things, etc. In particular,
the commit adds details of an example. I find this very helpful, because
it's taken me a long time to understand how this code works.
2024-07-19 15:25:55 +10:00
Nicholas Nethercote
ca6649516f Make Parser::num_bump_calls 0-indexed.
Currently in `collect_tokens_trailing_token`, `start_pos` and `end_pos`
are 1-indexed by `replace_ranges` is 0-indexed, which is really
confusing. Making them both 0-indexed makes debugging much easier.
2024-07-19 15:25:55 +10:00
Nicholas Nethercote
f9c7ca70cb Move inner_attr code downwards.
This puts it just before the `replace_ranges` initialization, which
makes sense because the two variables are closely related.
2024-07-19 15:25:54 +10:00
Nicholas Nethercote
1f67cf9e63 Remove final_attrs local variable.
It's no shorter than `ret.attrs()`, and `ret.attrs()` is used multiple
times earlier in the function.
2024-07-19 15:25:54 +10:00
Nicholas Nethercote
757f73f506 Simplify CaptureState::inner_attr_ranges.
The `Option`s within the `ReplaceRange`s within the hashmap are always
`None`. This PR omits them and inserts them when they are extracted from
the hashmap.
2024-07-19 15:25:54 +10:00
Kai Luo
ec805d17eb Revert format change 2024-07-19 13:02:51 +08:00
Kai Luo
c72df9ddf9 AIX uses .a as dylib's suffix 2024-07-19 12:40:09 +08:00
Michael Howell
0c932b763d
Rearrange sidebar modnav builder to more logical order 2024-07-18 19:49:32 -07:00
bors
3d68afc9e8 Auto merge of #127936 - matthiaskrgr:rollup-ci0eg7k, r=tgross35
Rollup of 8 pull requests

Successful merges:

 - #127418 (Wrap too long type name)
 - #127594 (Fuchsia status code match arm)
 - #127835 (Fix ICE in suggestion caused by `⩵` being recovered as `==`)
 - #127858 (match lowering: Rename `MatchPair` to `MatchPairTree`)
 - #127871 (Mention that type parameters are used recursively on bivariance error)
 - #127913 (remove `debug-logging` default from tools profile)
 - #127925 (Remove tag field from `Relation`s)
 - #127929 (Use more accurate span for `addr_of!` suggestion)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-19 02:05:32 +00:00
Nicholas Nethercote
4158a1c48f Only check force_collect in collect_tokens_trailing_token.
There are three places where we currently check `force_collect` and call
`collect_tokens_no_attrs` for `ForceCollect::Yes` and a vanilla parsing
function for `ForceCollect::No`.

But we can instead just pass in `force_collect` and let
`collect_tokens_trailing_token` do the appropriate thing.
2024-07-19 08:42:33 +10:00
Nicholas Nethercote
9d908a2877 Use ForceCollect in parse_attr_item.
Instead of a `bool`. Because `ForceCollect` is used in this way
everywhere else.
2024-07-19 08:24:54 +10:00
Nicholas Nethercote
7d7e2a173a Don't always force collect tokens in recover_stmt_local_after_let.
Use a parameter to decide whether to force collect, as is done for the
closely related `parse_local_mk` method.
2024-07-19 08:24:53 +10:00
Nicholas Nethercote
e69ff1c106 Remove an unnecessary ForceCollect::Yes.
No need to collect tokens on this recovery path, because the parsed
statement isn't even looked at.
2024-07-19 08:20:57 +10:00
Michael Goulet
2f5a84ea16 Don't allow unsafe statics outside of extern blocks 2024-07-18 18:02:29 -04:00
Veera
4cad705017 Parser: Suggest Placing the Return Type After Function Parameters 2024-07-18 17:56:34 -04:00
Matthias Krüger
d1250bc1d5
Rollup merge of #127929 - estebank:addr_of, r=compiler-errors
Use more accurate span for `addr_of!` suggestion

Use a multipart suggestion instead of a single whole-span replacement:

```
error[E0796]: creating a shared reference to a mutable static
  --> $DIR/reference-to-mut-static-unsafe-fn.rs:10:18
   |
LL |         let _y = &X;
   |                  ^^ shared reference to mutable static
   |
   = note: this shared reference has lifetime `'static`, but if the static ever gets mutated, or a mutable reference is created, then any further use of this shared reference is Undefined Behavior
help: use `addr_of!` instead to create a raw pointer
   |
LL |         let _y = addr_of!(X);
   |                  ~~~~~~~~~ +
```
2024-07-18 23:05:24 +02:00
Matthias Krüger
11688370dd
Rollup merge of #127925 - compiler-errors:tag, r=lcnr
Remove tag field from `Relation`s

Can just use the relation name w/ `std::any::type_name`. Also changes some printing to use instrument. Also changes some instrument levels to `trace` since I expect relations are somewhat hot, so having them print on debug is probably noisy.

r? lcnr
2024-07-18 23:05:24 +02:00
Matthias Krüger
f4a9f7f524
Rollup merge of #127913 - onur-ozkan:broken-defaults, r=Kobzol
remove `debug-logging` default from tools profile

`debug-logging` conflicts with `download-rustc` option, and doesn't really make sense to enable it for a profile that is used for tool development.
2024-07-18 23:05:23 +02:00
Matthias Krüger
65de5d0472
Rollup merge of #127871 - compiler-errors:recursive, r=estebank
Mention that type parameters are used recursively on bivariance error

Right now when a type parameter is used recursively, even with indirection (so it has a finite size) we say that the type parameter is unused:

```
struct B<T>(Box<B<T>>);
```

This is confusing, because the type parameter is *used*, it just doesn't have its variance constrained. This PR tweaks that message to mention that it must be used *non-recursively*.

Not sure if we should actually mention "variance" here, but also I'd somewhat prefer we don't keep the power users in the dark w.r.t the real underlying issue, which is that the variance isn't constrained. That technical detail is reserved for a note, though.

cc `@fee1-dead`

Fixes #118976
Fixes #26283
Fixes #53191
Fixes #105740
Fixes #110466
2024-07-18 23:05:22 +02:00
Matthias Krüger
4d5ba0d2c7
Rollup merge of #127858 - Zalathar:pair-tree, r=Nadrieril
match lowering: Rename `MatchPair` to `MatchPairTree`

In #120904, `MatchPair` became able to store other match pairs as children, forming a tree. That has made the old name confusing, so this patch renames the type to `MatchPairTree`.

This PR also includes a patch renaming the `test` method to `pick_test_for_match_pair`, since it would conflict with the main change.

r? `@Nadrieril`
2024-07-18 23:05:22 +02:00
Matthias Krüger
50a90e394e
Rollup merge of #127835 - estebank:issue-127823, r=compiler-errors
Fix ICE in suggestion caused by `⩵` being recovered as `==`

The second suggestion shown here would previously incorrectly assume that the span corresponding to `⩵` was 2 bytes wide composed by 2 1 byte wide chars, so a span pointing at `==` could point only at one of the `=` to remove it. Instead, we now replace the whole thing (as we should have the whole time):

```
error: unknown start of token: \u{2a75}
  --> $DIR/unicode-double-equals-recovery.rs:1:16
   |
LL | const A: usize ⩵ 2;
   |                ^
   |
help: Unicode character '⩵' (Two Consecutive Equals Signs) looks like '==' (Double Equals Sign), but it is not
   |
LL | const A: usize == 2;
   |                ~~

error: unexpected `==`
  --> $DIR/unicode-double-equals-recovery.rs:1:16
   |
LL | const A: usize ⩵ 2;
   |                ^
   |
help: try using `=` instead
   |
LL | const A: usize = 2;
   |                ~
```

Fix #127823.
2024-07-18 23:05:21 +02:00
Matthias Krüger
c1bbe347c2
Rollup merge of #127594 - c6c7:fuchsia-status-code-match-arm, r=tmandry
Fuchsia status code match arm

Adds a match arm for the Fuchsia status code upon a process abort. An additional change moves the Windows status code down into the match arm itself instead of being defined as a constant elsewhere.

r​? tmandry
2024-07-18 23:05:21 +02:00
Matthias Krüger
7c1bf86417
Rollup merge of #127418 - GuillaumeGomez:wrap-too-long-type-name, r=notriddle
Wrap too long type name

Fixes https://github.com/rust-lang/rust/issues/120595.

Takeover of #126209.

cc `@BradMarr`
r? `@notriddle`
2024-07-18 23:05:20 +02:00
Trevor Gross
8410348b1c Update the binary_asm_label message
The link pointed to a closed issue. Create a new one and point the link
to it.

Also add a help message to hint what change the user could make.

Fixes: https://github.com/rust-lang/rust/issues/127821
2024-07-18 17:00:43 -04:00
Oneirical
730313227f rewrite link-path-order to rmake 2024-07-18 16:27:34 -04:00
Trevor Gross
9387a7523e Change binary_asm_labels to only fire on x86 and x86_64
In <https://github.com/rust-lang/rust/pull/126922>, the
`binary_asm_labels` lint was added which flags labels such as `0:` and
`1:`. Before that change, LLVM was giving a confusing error on
x86/x86_64 because of an incorrect interpretation.

However, targets other than x86 and x86_64 never had the error message
and have not been a problem. This means that the lint was causing code
that previously worked to start failing (e.g. `compiler_builtins`),
rather than only providing a more clear messages where there has always
been an error.

Adjust the lint to only fire on x86 and x86_64 assembly to avoid this
regression.
2024-07-18 15:00:56 -05:00
Michael Howell
2e1e627430 rustdoc: fix current class on sidebar modnav 2024-07-18 12:06:21 -07:00
Guillaume Gomez
c820a2392c Add test for size of items in the items list 2024-07-18 20:48:20 +02:00
Guillaume Gomez
fed059270a Wrap too long item name and improve the item list display a bit 2024-07-18 20:48:20 +02:00
Esteban Küber
abf92c049d Use more accurate span for addr_of! suggestion
Use a multipart suggestion instead of a single whole-span replacement:

```
error[E0796]: creating a shared reference to a mutable static
  --> $DIR/reference-to-mut-static-unsafe-fn.rs:10:18
   |
LL |         let _y = &X;
   |                  ^^ shared reference to mutable static
   |
   = note: this shared reference has lifetime `'static`, but if the static ever gets mutated, or a mutable reference is created, then any further use of this shared reference is Undefined Behavior
help: use `addr_of!` instead to create a raw pointer
   |
LL |         let _y = addr_of!(X);
   |                  ~~~~~~~~~ +
```
2024-07-18 18:39:20 +00:00
Michael Goulet
8dbb63a585 Remove tag field from relations 2024-07-18 14:34:05 -04:00
Esteban Küber
33bd4bdeb5 Tweak "field not found" suggestion when giving struct literal for tuple struct type
```
error[E0560]: struct `S` has no field named `x`
  --> $DIR/nested-non-tuple-tuple-struct.rs:8:19
   |
LL | pub struct S(f32, f32);
   |            - `S` defined here
...
LL |     let _x = (S { x: 1.0, y: 2.0 }, S { x: 3.0, y: 4.0 });
   |                   ^ field does not exist
   |
help: `S` is a tuple struct, use the appropriate syntax
   |
LL |     let _x = (S(/* f32 */, /* f32 */), S { x: 3.0, y: 4.0 });
   |               ~~~~~~~~~~~~~~~~~~~~~~~
```
2024-07-18 18:20:35 +00:00