search graph: improve rebasing and add forced ambiguity support
Based on rust-lang/rust#142774
This slightly strengthens rebasing and actually checks for the property we want to maintain. There are two additional optimizations we can and should do here:
- we should be able to just always rebase if cycle heads already have a provisional result from a previous iteration
- we currently only apply provisional cache entries if the `path_to_entry` matches exactly. We should be able to extend this e.g. if you have an entry for `B` in `ABA` where the path `BA` is coinductive, then we can use this entry even if the current path from `A` to `B` is inductive.
---
I've also added support for `PathKind::ForcedAmbiguity` which always forced the initial provisional result to be ambiguous. A am using this for cycles involving negative reasons, which is currently only used by the fuzzer in https://github.com/lcnr/search_graph_fuzz. Consider the following setup: A goal `A` which only holds if `B` does not hold, and `B` which only holds if `A` does not hold.
- A only holds if B does not hold, results in X
- B only holds if A does not hold, results in !X
- A cycle, provisional result X
- B only holds if A does not hold, results in X
- A only holds if B does not hold, results in !X
- B cycle, provisional result X
With negative reasoning, the result of cycle participants depends on their position in the cycle. This means using cache entries while other entries are on the stack/have been popped is wrong. It's also generally just kinda iffy. By always forcing the initial provisional result of such cycles to be ambiguity, we can avoid this, as "not maybe" is just "maybe" again.
Rust kind of has negative reasoning due to incompleteness, consider the following setup:
- `T::Foo eq u32`
- normalize `T::Foo`
- via impl -> `u32`
- via param_env -> `T`
- nested goals...
`T::Foo eq u32` holds exactly if the nested goals of the `param_env` candidate do not hold, as preferring that candidate over the impl causes the alias-relate to fail. This means the current provisional cache may cause us to ignore `param_env` preference in rare cases. This is not unsound and I don't care about it, as we already have this behavior when rerunning on changed fixpoint results:
- `T: Trait`
- via impl ok
- via env
- `T: Trait` non-productive cycle
- result OK, rerun changed provisional result
- `T: Trait`
- via impl ok
- via env
- `T: Trait` using the provisional result, can be thought of as recursively expanding the proof tree
- via impl ok
- via env <don't care>
- prefer the env candidate, reached fixpoint
---
One could imaging changing `ParamEnv` candidates or the impl shadowing check to use `PathKind::ForcedAmbiguity` to make the search graph less observable instead of only using it for fuzzing. However, incomplete candidate preference isn't really negative reasoning and doing this is a breaking change https://github.com/rust-lang/trait-system-refactor-initiative/issues/114
r? `@compiler-errors`
Ship correct Cranelift library in its dist component
The first commit adds a post-dist UI test to check that Cranelift can be used with the extracted dist x64 Linux archive.
The original codegen copy logic in the Cranelift dist step was a bit redundant, and I didn't notice in https://github.com/rust-lang/rust/pull/144787 that it's copying the codegen backend from the build compiler's sysroot, rather than the target compiler's sysroot. The second commit modifies the logic to directly access the built codegen file (there is no need to search for it in the compiler's sysroot, in fact when you run just `x dist rustc_codegen_cranelift`, it shouldn't "taint" the sysroot with the codegen backend! Which it did before https://github.com/rust-lang/rust/pull/144787) and copy it to the tarball under a normalized name. Thus we get around any similar potential issues in the future, and make previously implicit logic more explicit.
This also fixes running just `x dist rustc_codegen_cranelift` without enabling `cranelift` in `rust.codegen-backends`, which should have been enabled by https://github.com/rust-lang/rust/pull/144787, but it didn't work fully, because the dist step tried to copy the codegen backend from the compiler's sysroot, but it didn't contain the codegen backend if it was not enabled by `rust.codegen-backends`.
Fixes: https://github.com/rust-lang/rust/issues/145201
try-job: dist-x86_64-linux
Fix Cargo cross-compilation (take two)
In https://github.com/rust-lang/rust/pull/145083, I fixed the case of manually invoking `x dist cargo`, but I realized that `x install` creates the `tool::Cargo` step through the `from_build_frompiler` constructor, which doesn't go through `get_tool_target_compiler`. So we just prepare both the host and target stdlibs directly before building Cargo. Ideally we would get rid of `from_build_compiler`, but that will require refactoring the dist and test steps, which is upcoming.
Hopefully fixes https://github.com/rust-lang/rust/issues/145059 for good.
Improve suggestion for "missing function argument" on multiline call
`rustc` has a very neat suggestion when the argument count does not match, with a nice placeholder that shows where an argument may be missing. Unfortunately the suggestion is always single-line, even when the function call spans across multiple lines. With this PR, `rustc` tries to guess if the function call is multiline or not, and emits a multiline suggestion when required.
r? `@jdonszelmann`
Fix macro infinite recursion test to not trigger warning about semicolon in expr
The test cases for rust-lang/rust#41731 are about infinite macro recursion that
incorporates `print!` and `println!`. However, they also included
trailing semicolons despite expanding to expressions; that isn't what
these particular test cases are designed to test.
Eliminate the trailing semicolons, to simplify future work on removing
this special case. Every *other* macro that expands to a semicolon in an
expression is a test case for that specifically.
Ignore coroutine witness type region args in auto trait confirmation
## The problem
Consider code like:
```
async fn process<'a>() {
Box::pin(process()).await;
}
fn require_send(_: impl Send) {}
fn main() {
require_send(process());
}
```
When proving that the coroutine `{coroutine@process}::<'?0>: Send`, we end up instantiating a nested goal `{witness@process}::<'?0>: Send` by synthesizing a witness type from the coroutine's args:
Proving a coroutine witness type implements an auto trait requires looking up the coroutine's witness types. The witness types are a binder that look like `for<'r> { Pin<Box<{coroutine@process}::<'r>>> }`. We instantiate this binder with placeholders and prove `Send` on the witness types. This ends up eventually needing to prove something like `{coroutine@process}::<'!1>: Send`. Repeat this process, and we end up in an overflow during fulfillment, since fulfillment does not use freshening.
This can be visualized with a trait stack that ends up looking like:
* `{coroutine@process}::<'?0>: Send`
* `{witness@process}::<'?0>: Send`
* `Pin<Box<{coroutine@process}::<'!1>>>: Send`
* `{coroutine@process}::<'!1>: Send`
* ...
* `{coroutine@process}::<'!2>: Send`
* `{witness@process}::<'!2>: Send`
* ...
* overflow!
The problem here specifically comes from the first step: synthesizing a witness type from the coroutine's args.
## Why wasn't this an issue before?
Specifically, before 63f6845e570305a92eaf855897768617366164d6, this wasn't an issue because we were instead extracting the witness from the coroutine type itself. It turns out that given some `{coroutine@process}::<'?0>`, the witness type was actually something like `{witness@process}::<'erased>`!
So why do we end up with a witness type with `'erased` in its args? This is due to the fact that opaque type inference erases all regions from the witness. This is actually explicitly part of opaque type inference -- changing this to actually visit the witness types actually replicates this overflow even with 63f6845e570305a92eaf855897768617366164d6 reverted:
ca77504943/compiler/rustc_borrowck/src/type_check/opaque_types.rs (L303-L313)
To better understand this difference and how it avoids a cycle, if you look at the trait stack before 63f6845e570305a92eaf855897768617366164d6, we end up with something like:
* `{coroutine@process}::<'?0>: Send`
* `{witness@process}::<'erased>: Send` **<-- THIS CHANGED**
* `Pin<Box<{coroutine@process}::<'!1>>>: Send`
* `{coroutine@process}::<'!1>: Send`
* ...
* `{coroutine@process}::<'erased>: Send` **<-- THIS CHANGED**
* `{witness@process}::<'erased>: Send` **<-- THIS CHANGED**
* coinductive cycle! 🎉
## So what's the fix?
This hack replicates the behavior in opaque type inference to erase regions from the witness type, but instead erasing the regions during auto trait confirmation. This is kinda a hack, but is sound. It does not need to be replicated in the new trait solver, of course.
---
I hope this explanation makes sense.
We could beta backport this instead of the revert https://github.com/rust-lang/rust/pull/145193, but then I'd like to un-revert that on master in this PR along with landing this this hack. Thoughts?
r? lcnr
`NllRegionVariableOrigin` remove `from_forall`
See added comment in the only place it was used.
cc rust-lang/rust#144988 `@amandasystems,` going to merge that PR first.
Check coroutine upvars in dtorck constraint
Fixrust-lang/rust#144155.
This PR fixes an unsoundness where we were not considering coroutine upvars as drop-live if the coroutine interior types (witness types) had nothing which required drop.
In the case that the coroutine does not have any interior types that need to be dropped, then we don't need to treat all of the upvars as use-live; instead, this PR uses the same logic as closures, and descends into the upvar types to collect anything that must be drop-live. The rest of this PR is reworking the comment to explain the behavior here.
r? `@lcnr` or reassign 😸
---
Just some thoughts --- a proper fix for this whole situation would be to consider `TypingMode` in the `needs_drop` function, and just calling `coroutine_ty.needs_drop(tcx, typing_env)` in the dtorck constraint check.
During MIR building, we should probably use a typing mode that stalls the local coroutines and considers them to be unconditionally drop, or perhaps just stall *all* coroutines in analysis mode. Then in borrowck mode, we can re-check `needs_drop` but descend into witness types properly. https://github.com/rust-lang/rust/pull/144158 implements this experimentally.
This is a pretty involved fix, and conflicts with some in-flight changes (rust-lang/rust#144157) that I have around removing coroutine witnesses altogether. I'm happy to add a FIXME to rework this whole approach, but I don't want to block this quick fix since it's obviously more correct than the status-quo.
Reject relaxed bounds inside associated type bounds (ATB)
**Reject** relaxed bounds — most notably `?Sized` — inside associated type bounds `TraitRef<AssocTy: …>`.
This was previously accepted without warning despite being incorrect: ATBs are *not* a place where we perform *sized elaboration*, meaning `TraitRef<AssocTy: …>` does *not* elaborate to `TraitRef<AssocTy: Sized + …>` if `…` doesn't contain `?Sized`. Therefore `?Sized` is meaningless. In no other (stable) place do we (intentionally) allow relaxed bounds where we don't also perform sized elab, this is highly inconsistent and confusing! Another point of comparison: For the desugared `$SelfTy: TraitRef, $SelfTy::AssocTy: …` we don't do sized elab either (and thus also don't allow relaxed bounds).
Moreover — as I've alluded to back in https://github.com/rust-lang/rust/pull/135841#pullrequestreview-2619462717 — some later validation steps only happen during sized elaboration during HIR ty lowering[^1]. Namely, rejecting duplicates (e.g., `?Trait + ?Trait`) and ensuring that `Trait` in `?Trait` is equal to `Sized`[^2]. As you can probably guess, on stable/master we don't run these checks for ATBs (so we allow even more nonsensical bounds like `Iterator<Item: ?Copy>` despite T-types's ruling established in the FCP'ed rust-lang/rust#135841).
This PR rectifies all of this. I cratered this back in 2025-01-10 with (allegedly) no regressions found ([report](https://github.com/rust-lang/rust/pull/135331#issuecomment-2585330783), [its analysis](https://github.com/rust-lang/rust/pull/135331#issuecomment-2585356422)). [However a contributor manually found two occurrences](https://github.com/rust-lang/rust/issues/135229#issuecomment-2581832852) of `TraitRef<AssocTy: ?Sized>` in small hobby projects (presumably via GH code search). I immediately sent downstream PRs: https://github.com/Gui-Yom/turbo-metrics/pull/14, https://github.com/ireina7/summon/pull/1 (however, the owners have showed no reaction so far).
I'm leaning towards banning these forms **without a FCW** because a FCW isn't worth the maintenance cost[^3]. Note that associated type bounds were stabilized in 1.79.0 (released 2024-06-13 which is 13 months ago), so the proliferation of ATBs shouldn't be that high yet. If you think we should do another crater run since the last one was 6 months ago, I'm fine with that.
Fixesrust-lang/rust#135229.
[^1]: I consider this a flaw in the implementation and [I've already added a huge FIXME](82a02aefe0/compiler/rustc_hir_analysis/src/hir_ty_lowering/bounds.rs (L195-L207)).
[^2]: To be more precise, if the internal flag `-Zexperimental-default-bounds` is provided other "default traits" (needs internal feature `lang_items`) are permitted as well (cc closely related internal feature: `more_maybe_bounds`).
[^3]: Having to track this and adding an entire lint whose remnants would remain in the code base forever (we never *fully* remove lints).
Enforce in bootstrap that doc must have stage at least 1
Following with the bootstrap cleanups, this time around `doc` steps. Should be pretty straightforward, because the supporting infrastructure was already there.
The only thing I found a bit fishy is using `Mode::ToolBootstrap` as a "catch-all" mode for non-rustc-private steps in `tool_doc!`, but I don't think that we need to distinguish the tools in some special way when documenting them, apart from supporting `rustc_private`.
Before, `x doc` more or less defaulted to what we call stage 2 now. Now it is properly stage 1, so e.g. `x doc compiler` documents the compiler using the stage0/beta rust(do)c.
r? `@jieyouxu`
try-job: dist-aarch64-msvc
Tweak spans providing type context on errors when involving macros
Do not point at macro invocation multiple times when we try to add span labels mentioning what type each expression has, which is unnecessary when the error is at a macro invocation.
Make config method invoke inside parse use dwn_ctx
This PR is part of a series of config refactorings. It removes calls from config methods to solid functions defined in `config.rs`. After this, we will remove the default dependencies in the config.
r? ```@Kobzol```
Point at the `Fn()` or `FnMut()` bound that coerced a closure, which caused a move error
When encountering a move error involving a closure because the captured value isn't `Copy`, and the obligation comes from a bound on a type parameter that requires `Fn` or `FnMut`, we point at it and explain that an `FnOnce` wouldn't cause the move error.
```
error[E0507]: cannot move out of `foo`, a captured variable in an `Fn` closure
--> f111.rs:15:25
|
14 | fn do_stuff(foo: Option<Foo>) {
| --- ----------- move occurs because `foo` has type `Option<Foo>`, which does not implement the `Copy` trait
| |
| captured outer variable
15 | require_fn_trait(|| async {
| -- ^^^^^ `foo` is moved here
| |
| captured by this `Fn` closure
16 | if foo.map_or(false, |f| f.foo()) {
| --- variable moved due to use in coroutine
|
help: `Fn` and `FnMut` closures require captured values to be able to be consumed multiple times, but an `FnOnce` consume them only once
--> f111.rs:12:53
|
12 | fn require_fn_trait<F: Future<Output = ()>>(_: impl Fn() -> F) {}
| ^^^^^^^^^
help: consider cloning the value if the performance cost is acceptable
|
16 | if foo.clone().map_or(false, |f| f.foo()) {
| ++++++++
```
Fixrust-lang/rust#68119, by pointing at `Fn` and `FnMut` bounds involved in move errors.
std: sys: io: io_slice: Add UEFI types
UEFI networking APIs do support vectored read/write. While the types for UDP4, UDP6, TCP4 and TCP6 are defined separately, they are essentially the same C struct. So we can map IoSlice and IoSliceMut to have the same binary representation.
Since all UEFI networking types for read/write are DSTs, `IoSlice` and `IoSliceMut` will need to be copied to the end of the transmit/receive structures. So having the same binary representation just allows us to do a single memcpy instead of having to loop and set the DST.
cc ``@nicholasbishop``
document assumptions about `Clone` and `Eq` traits
Most standard library collections break if `Clone` has a non-standard implementation which violates `x.clone() == x`. [Here](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=b7fc6dfa8410cbb673eb8d38393d81de) the resulting broken behaviour of different collections is shown. I originally created an issue at https://github.com/rust-lang/hashbrown/issues/629, but the conclusion there was that `x.clone()` resulting in an object that compares equal to the original one is probably a very universal assumption. However, this assumption is (to my knowledge) not documented anywhere.
I propose to make this assumption explicit in the `Clone` trait documentation. The property that seems the most reasonable to me is the following: When implementing both `Clone` and `PartialEq`, then
```text
x == x -> x.clone() == x
```
is expected to hold. This way, when also implementing `Eq`, it automatically follows that `x.clone() == x` has to hold, which should be enough for the collections to not break. At the same time, the property also works for the "normal" elements of a type with `PartialEq`. For the wording, I tried to follow the [`Hash` and `Eq`](https://doc.rust-lang.org/std/hash/trait.Hash.html#hash-and-eq) documentation.
As I am fairly new to Rust, it might well be that this property cannot be generally expected – it seems reasonable to me, but any counter-examples or critique, both content- and wording-wise, would be very welcome. If the property turns out to be too general, I would suggest to at least document the assumption of `x.clone() == x` for the collections somehow.
An additional thought of mine:
If it is indeed generally expected that `x == x -> x.clone() == x`, then, for the sake of completeness, one could also define that `x != x -> y != y for y = x.clone()` should hold, i.e., that an object that did not compare equal to itself before cloning, should also not compare equal to itself afterwards.
Constify remaining traits/impls for `const_ops`
Tracking issue: rust-lang/rust#143802
This is split into two commits for ease of reviewability:
1. Updates the `forward_ref_*` macros to accept multiple attributes (in anticipation of needing `rust_const_unstable` attributes) and also *require* attributes in these macros. Since the default attribute only helps for the initial implementations, it means it's easy to get wrong for future implementations, as shown for the saturating implementations which were incorrect before.
2. Actually constify the traits/impls.
A few random other notes on the implementation specifically:
* I unindented the attributes that were passed to the `forward_ref_*` macro calls because in some places rustfmt wanted them to be unindented, and in others it was allowed because they were themselves inside of macro bodies. I chose the consistent indenting even though I (personally) think it looks worse.
----
As far as the actual changes go, this constifies the following additional traits:
* `Neg`
* `Not`
* `BitAnd`
* `BitOr`
* `BitXor`
* `Shl`
* `Shr`
* `AddAssign`
* `SubAssign`
* `MulAssign`
* `DivAssign`
* `RemAssign`
* `BitAndAssign`
* `BitOrAssign`
* `BitXorAssign`
* `ShlAssign`
* `ShrAssign`
In terms of constified implementations of these traits, it adds the reference-forwarded versions of all the arithmetic operators, which are defined by the macros in `library/core/src/internal_macros.rs`. I'm not going to fully enumerate these because we'd be here all day, but sufficed to say, it effectively allows adding an `&` to one or both sides of an operator for primitives.
Additionally, I constified the implementations for `Wrapping`, `Saturating`, and `NonZero` as well, since all of them forward to already-const-stable methods. (potentially via intrinsics, to avoid extra overhead)
There are three "non-primitive" types which implement these traits, listed below. Note that I put "non-primitive" in quotes since I'm including `Wrapping`, `Saturating`, and `NonZero`, which are just wrappers over primitives.
* `Duration` (arithmetic operations)
* `SystemTime` (arithmetic operations)
* `Ipv4Addr` (bit operations)
* `Ipv6Addr` (bit operations)
Additionally, because the methods on `SystemTime` needed to make these operations const were not marked const, a separate tracking issue for const-stabilising those methods is rust-lang/rust#144517.
Stuff left out of this PR:
* `Assume` (this could trivially be made const, but since the docs indicate this is still under heavy design, I figured I'd leave it out)
* `Instant` (this could be made const, but cannot reasonably be constructed at constant time, so, isn't useful)
* `SystemTime` (will submit separate PR)
* SIMD types (I'm tackling these all at once later; see rust-lang/portable-simd#467)
<!-- TRIAGEBOT_START -->
<!-- TRIAGEBOT_CONCERN-ISSUE_START -->
> [!NOTE]
> # Concerns (0 active)
>
> - ~~[May break Clippy](https://github.com/rust-lang/rust/pull/143949#issuecomment-3081466077)~~ resolved in [this comment](https://github.com/rust-lang/rust/pull/143949#issuecomment-3083628215)
>
> *Managed by ```@rustbot`—see`` [help](https://forge.rust-lang.org/triagebot/concern.html) for details.*
<!-- TRIAGEBOT_CONCERN-ISSUE_END -->
<!-- TRIAGEBOT_END -->
Detect struct construction with private field in field with default
When trying to construct a struct that has a public field of a private type, suggest using `..` if that field has a default value.
```
error[E0603]: struct `Priv1` is private
--> $DIR/non-exhaustive-ctor-2.rs:19:39
|
LL | let _ = S { field: (), field1: m::Priv1 {} };
| ------ ^^^^^ private struct
| |
| while setting this field
|
note: the struct `Priv1` is defined here
--> $DIR/non-exhaustive-ctor-2.rs:14:4
|
LL | struct Priv1 {}
| ^^^^^^^^^^^^
help: the type `Priv1` of field `field1` is private, but you can construct the default value defined for it in `S` using `..` in the struct initializer expression
|
LL | let _ = S { field: (), .. };
| ~~
```
Do not point at macro invocation which expands to an inference error. Avoid the following:
```
error[E0308]: mismatched types
--> $DIR/does-not-have-iter-interpolated.rs:12:5
|
LL | quote!($($nonrep)*);
| ^^^^^^^^^^^^^^^^^^^
| |
| expected `HasIterator`, found `ThereIsNoIteratorInRepetition`
| expected due to this
| here the type of `has_iter` is inferred to be `ThereIsNoIteratorInRepetition`
```
The test cases for issue 41731 are about infinite macro recursion that
incorporates `print!` and `println!`. However, they also included
trailing semicolons despite expanding to expressions; that isn't what
these particular test cases are designed to test.
Eliminate the trailing semicolons, to simplify future work on removing
this special case. Every *other* macro that expands to a semicolon in an
expression is a test case for that specifically.
Fix typo with paren rustc_llvm/build.rs
The current parenthesis looks suspect: it means that OpenHarmony is always excluded whereas it looks like it was intended to only be excluded if the architecture was Arm.
Since Rust doesn't support the other architectures with OpenHarmony, there currently isn't a bug but this cleans up some suspicious code and avoids a potential future annoyance for someone trying to bring up a new triple.
r? `@Amanieu`
Use `eq_ignore_ascii_case` to avoid heap alloc in `detect_confuse_type`
A small optimization has been made, using `to_ascii_lowercase()` instead of `to_lowercase().to_string()`.
r? compiler
Replace unsafe `security_attributes` function with safe `inherit_handle` alternative
The `security_attributes` function is marked as safe despite taking a raw pointer which will later be used. Fortunately this function is only used internally and only in one place that has been basically the same for a decade now. However, we only ever set one bool so it's easy enough to replace with something that's actually safe.
In the future we might want to expose the ability for users to set security attributes. But that should be properly designed (and safe!).
Add regression test for `saturating_sub` bounds check issue
Add codegen test for issue where `valid_index.saturating_sub(X)` produced an extra bounds check.
This was fixed by the LLVM upgrade.
Closesrust-lang/rust#139759
Rehome 32 `tests/ui/issues/` tests to other subdirectories under `tests/ui/`
rust-lang/rust#143902 divided into smaller, easier to review chunks.
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that `@Kivooeo` was using.
r? `@jieyouxu`
When encountering a move error involving a closure because the captured value isn't `Copy`, and the obligation comes from a bound on a type parameter that requires `Fn` or `FnMut`, we point at it and explain that an `FnOnce` wouldn't cause the move error.
```
error[E0507]: cannot move out of `foo`, a captured variable in an `Fn` closure
--> f111.rs:15:25
|
14 | fn do_stuff(foo: Option<Foo>) {
| --- ----------- move occurs because `foo` has type `Option<Foo>`, which does not implement the `Copy` trait
| |
| captured outer variable
15 | require_fn_trait(|| async {
| -- ^^^^^ `foo` is moved here
| |
| captured by this `Fn` closure
16 | if foo.map_or(false, |f| f.foo()) {
| --- variable moved due to use in coroutine
|
help: `Fn` and `FnMut` closures require captured values to be able to be consumed multiple times, but an `FnOnce` consume them only once
--> f111.rs:12:53
|
12 | fn require_fn_trait<F: Future<Output = ()>>(_: impl Fn() -> F) {}
| ^^^^^^^^^
help: consider cloning the value if the performance cost is acceptable
|
16 | if foo.clone().map_or(false, |f| f.foo()) {
| ++++++++
```
When trying to construct a struct that has a public field of a private type, suggest using `..` if that field has a default value.
```
error[E0603]: struct `Priv1` is private
--> $DIR/non-exhaustive-ctor.rs:25:39
|
LL | let _ = S { field: (), field1: m::Priv1 {} };
| ------ ^^^^^ private struct
| |
| while setting this field
|
note: the struct `Priv1` is defined here
--> $DIR/non-exhaustive-ctor.rs:14:4
|
LL | struct Priv1 {}
| ^^^^^^^^^^^^
help: the field `field1` you're trying to set has a default value, you can use `..` to use it
|
LL | let _ = S { field: (), .. };
| ~~
```
