diff options
| author | bors[bot] <26634292+bors[bot]@users.noreply.github.com> | 2021-11-10 21:08:51 +0000 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2021-11-10 21:08:51 +0000 |
| commit | 1e8d1e84b239dac33228cd95b42dbd77288eb557 (patch) | |
| tree | b7e5dc9fa50bd31316e4090293acac88188febc3 /tests/mir-opt/lower_array_len.array_len_raw.NormalizeArrayLen.diff | |
| parent | e7244e899f84721857d9702479c051292862f7f9 (diff) | |
| parent | 0d54754ca73d8f370a902f605c94f4b588ded532 (diff) | |
| download | rust-1e8d1e84b239dac33228cd95b42dbd77288eb557.tar.gz rust-1e8d1e84b239dac33228cd95b42dbd77288eb557.zip | |
Merge #10689
10689: Handle pub tuple fields in tuple structs r=Veykril a=adamrk The current implementation will throw a parser error for tuple structs that contain a pub tuple field. For example, ```rust struct Foo(pub (u32, u32)); ``` is valid Rust, but rust-analyzer will throw a parser error. This is because the parens after `pub` is treated as a visibility context. Allowing a tuple type to follow `pub` in the special case when we are defining fields in a tuple struct can fix the issue. I guess this is a really minor case because there's not much reason for having a tuple type within a struct tuple, but it is valid rust syntax... Co-authored-by: Adam Bratschi-Kaye <ark.email@gmail.com>
Diffstat (limited to 'tests/mir-opt/lower_array_len.array_len_raw.NormalizeArrayLen.diff')
0 files changed, 0 insertions, 0 deletions
