Uh oh!
There was an error while loading. Please reload this page.
Suggest making private tuple struct field public - #106579
Conversation
rustbot
commented
Jan 8, 2023
r? @Nilstrieb (rustbot has picked a reviewer for you, use r? to override) |
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Would it make sense to extend and reuse the field_names field for this?
There was a problem hiding this comment.
field_names only had the Symbol and I wasn't sure if there was any place that relied on it being always a Vec, causing perf impact if needing to map/collect it every time. But yes, we could do that :)
There was a problem hiding this comment.
The only difference I see is that this approach will only store the privacy span vec for tuple structs and nothing else.
Uh oh!
There was an error while loading. Please reload this page.
a6c6886 to
9369bfaCompare* Account for `struct S(pub(super)Ty);` in suggestion * Suggest changing field visibility in E0603 too
Noratrieb
commented
Jan 12, 2023
@bors r+ |
bors
commented
Jan 12, 2023
Suggest making private tuple struct field public Fixrust-lang#52144.
Rollup of 6 pull requests Successful merges: - rust-lang#105806 (Support eager subdiagnostics again) - rust-lang#106322 (Handle inference variables in `CollectAllMismatches` correctly) - rust-lang#106579 (Suggest making private tuple struct field public) - rust-lang#106714 (remove unreachable error code `E0490`) - rust-lang#106751 (Fix rendering 'const' in header for intrinsics) - rust-lang#106761 (Add `WaffleLapkin` to compiler reviewers) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Fix#52144.