Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add UnnamedField type and refactor FieldDef to allow unnamed fields #84415

Closed
wants to merge 5 commits into from

Conversation

jedel1043
Copy link
Contributor

@jedel1043 jedel1043 commented Apr 21, 2021

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
Copy link
Collaborator

Some changes occurred in src/tools/clippy.

cc @rust-lang/clippy

@rust-highfive
Copy link
Collaborator

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-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 21, 2021
@jedel1043 jedel1043 changed the title Add UnnamedField type and refactor FieldDef to allow unnamed fields (#49804) Add UnnamedField type and refactor FieldDef to allow unnamed fields Apr 21, 2021
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@petrochenkov petrochenkov self-assigned this Apr 22, 2021
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer
Copy link
Collaborator

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
Copy link
Contributor

bors commented Apr 24, 2021

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

@petrochenkov
Copy link
Contributor

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

@petrochenkov petrochenkov added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 24, 2021
@jedel1043
Copy link
Contributor Author

jedel1043 commented Apr 24, 2021

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
Copy link
Contributor

@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
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants