Add UnnamedField type and refactor FieldDef to allow unnamed fields

[jedel1043]

Additionally added the unnamed_fields feature gate.

Covers the Parsing section of the RFC 2102. Hopefully this can allow a full implementation of the feature.

[rust-highfive]

Some changes occurred in src/tools/clippy.

cc @rust-lang/clippy

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @estebank (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[rust-log-analyzer]

The job x86_64-gnu-llvm-10 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

.................................................................................................... 9400/11771
.................................................................................................... 9500/11771
.................................................................................................... 9600/11771
i......i............................................................................................ 9700/11771
..............................................iiiiiii..iiiiii.i..................................... 9800/11771
.................................................................................................... 10000/11771
.................................................................................................... 10100/11771
.................................................................................................... 10200/11771
.................................................................................................... 10300/11771
---
..............................................................i.i................................... 11700/11771
.......................................................................
failures:

---- [ui] ui/feature-gates/feature-gate-unnamed_fields.rs stdout ----

error: Error: expected failure status (Some(1)) but received status Some(101).
status: exit status: 101
command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/ui/feature-gates/feature-gate-unnamed_fields.rs" "-Zthreads=1" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zemit-future-incompat-report" "--emit" "metadata" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/feature-gates/feature-gate-unnamed_fields" "-A" "unused" "-Crpath" "-O" "-Cdebuginfo=0" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/feature-gates/feature-gate-unnamed_fields/auxiliary"
------------------------------------------

------------------------------------------
stderr:
stderr:
Some tests failed in compiletest suite=ui mode=ui host=x86_64-unknown-linux-gnu target=x86_64-unknown-linux-gnu
------------------------------------------
thread 'rustc' panicked at 'no entry for node id: `NodeId(12)`', compiler/rustc_resolve/src/lib.rs:1144:55

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.
note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.53.0-nightly (eb8b58ff6 2021-04-22) running on x86_64-unknown-linux-gnu

note: compiler flags: -Z threads=1 -Z ui-testing -Z deduplicate-diagnostics=no -Z emit-future-incompat-report -Z unstable-options -C codegen-units=1 -C prefer-dynamic -C rpath -C debuginfo=0
query stack during panic:
end of query stack

------------------------------------------
---
test result: FAILED. 11673 passed; 1 failed; 97 ignored; 0 measured; 0 filtered out; finished in 117.72s



command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/ui" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--suite" "ui" "--mode" "ui" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-10/bin/FileCheck" "--nodejs" "/usr/bin/node" "--host-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--target-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python3" "--lldb-python" "/usr/bin/python3" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "10.0.0" "--llvm-components" "aarch64 aarch64asmparser aarch64codegen aarch64desc aarch64disassembler aarch64info aarch64utils aggressiveinstcombine all all-targets amdgpu amdgpuasmparser amdgpucodegen amdgpudesc amdgpudisassembler amdgpuinfo amdgpuutils analysis arm armasmparser armcodegen armdesc armdisassembler arminfo armutils asmparser asmprinter avr avrasmparser avrcodegen avrdesc avrdisassembler avrinfo binaryformat bitreader bitstreamreader bitwriter bpf bpfasmparser bpfcodegen bpfdesc bpfdisassembler bpfinfo cfguard codegen core coroutines coverage debuginfocodeview debuginfodwarf debuginfogsym debuginfomsf debuginfopdb demangle dlltooldriver dwarflinker engine executionengine frontendopenmp fuzzmutate globalisel hexagon hexagonasmparser hexagoncodegen hexagondesc hexagondisassembler hexagoninfo instcombine instrumentation interpreter ipo irreader jitlink lanai lanaiasmparser lanaicodegen lanaidesc lanaidisassembler lanaiinfo libdriver lineeditor linker lto mc mca mcdisassembler mcjit mcparser mips mipsasmparser mipscodegen mipsdesc mipsdisassembler mipsinfo mirparser msp430 msp430asmparser msp430codegen msp430desc msp430disassembler msp430info native nativecodegen nvptx nvptxcodegen nvptxdesc nvptxinfo objcarcopts object objectyaml option orcerror orcjit passes perfjitevents powerpc powerpcasmparser powerpccodegen powerpcdesc powerpcdisassembler powerpcinfo profiledata remarks riscv riscvasmparser riscvcodegen riscvdesc riscvdisassembler riscvinfo riscvutils runtimedyld scalaropts selectiondag sparc sparcasmparser sparccodegen sparcdesc sparcdisassembler sparcinfo support symbolize systemz systemzasmparser systemzcodegen systemzdesc systemzdisassembler systemzinfo tablegen target textapi transformutils vectorize webassembly webassemblyasmparser webassemblycodegen webassemblydesc webassemblydisassembler webassemblyinfo windowsmanifest x86 x86asmparser x86codegen x86desc x86disassembler x86info x86utils xcore xcorecodegen xcoredesc xcoredisassembler xcoreinfo xray" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"


failed to run: /checkout/obj/build/bootstrap/debug/bootstrap --stage 2 test --exclude src/tools/tidy
Build completed unsuccessfully in 0:12:18

[bors]

☔ The latest upstream changes (presumably #84525) made this pull request unmergeable. Please resolve the merge conflicts.

[petrochenkov]

I don't think this is a good implementation direction in general.
It introduces the unnamed field like some kind of single indivisible construction while there are clear components in it - the name (_) and the type (struct { ... } or union { ... }).

So a preferred solution (compatible with macros, and also current treatment of other syntaxes with similar "limited contexts" like ... types in function signatures or .. patterns inside tuple/slice patterns) would be to:

• Accept _ in field names during parsing, no AST changes is necessary (gate it at parse time, search for sess.gated_spans.gate(...) for examples).
• Introduce two new variants to enum TyKind - AnonymousStruct and AnonymousUnion and parse struct { ... } or union { ... } into them in fn parse_ty_common (again, gate them at parse time).
• Produce semantic errors on all occurrences of the new TyKinds outside of field definitions (in ast_validation.rs).

r? @petrochenkov

[jedel1043]

I don't think this is a good implementation direction in general.
It introduces the unnamed field like some kind of single indivisible construction while there are clear components in it - the name (_) and the type (struct { ... } or union { ... }).

So a preferred solution (compatible with macros, and also current treatment of other syntaxes with similar "limited contexts" like ... types in function signatures or .. patterns inside tuple/slice patterns) would be to:

• Accept _ in field names during parsing, no AST changes is necessary (gate it at parse time, search for sess.gated_spans.gate(...) for examples).
• Introduce two new variants to enum TyKind - AnonymousStruct and AnonymousUnion and parse struct { ... } or union { ... } into them in fn parse_ty_common (again, gate them at parse time).
• Produce semantic errors on all occurrences of the new TyKinds outside of field definitions (in ast_validation.rs).

I think you're right, maybe I was overengineering the implementation a little bit too much. Should I close this PR and open another one with the new implementation?

[petrochenkov]

@jedel1043

Should I close this PR and open another one with the new implementation?

You can make a new PR, or reuse this PR, whatever is more convenient.

[jedel1043]

Made a new implementation prototype based on @petrochenkov 's advice, so closing this PR.