public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Thomas Schwinge <tschwinge@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc/devel/rust/master] Merge #1608 Date: Sat, 22 Oct 2022 10:48:47 +0000 (GMT) [thread overview] Message-ID: <20221022104847.146DC38582A3@sourceware.org> (raw) https://gcc.gnu.org/g:490aa25d5564313c1957bf28533fe902a0aaa1f2 commit 490aa25d5564313c1957bf28533fe902a0aaa1f2 Merge: 60b21d2f58f 05bd0555fa3 Author: bors[bot] <26634292+bors[bot]@users.noreply.github.com> Date: Fri Oct 21 14:13:47 2022 +0000 Merge #1608 1608: Initial support for closures r=philberty a=philberty This patch series introduces initial support for closures. Rust's implementation of closures is actually pretty clever, the function signatures for closures is driven by the specific FnTrait that the closure implements, this means a CallExpr to a closure becomes a method-call expr with the receiver type being the closure itself using the normal autoderef mechanism to do method selection for an implicit impl block. See https://github.com/rust-lang/rust/blob/7807a694c2f079fd3f395821bcc357eee8650071/library/core/src/ops/function.rs#L54-L71 The other implicit part of this is that arguments being passed to a closure _must_ be passed as a tuple. The down side of allowing libcore to specify the signatures of the closure functions is that we are limited in how we pass arguments, but using a tuple and then using similar machinery from the match-expr to restructure the parameter access to become the tuple accessors makes it look seamless. For example: ```rust let closure_annotated = |i: i32| -> i32 { i + 123 }; let i = 1; closure_annotated(i); ``` Wil generate a function and call-expr such as: ```c i32 test::main::{{closure}} (struct {{closure}} $closure, struct (i32) args) { _1 = args.__0; // this is 'i' return _1 + 123; } __attribute__((cdecl)) i32 test::main () { struct { i32 __0; } D.137; i32 D.140; const i32 a; const struct{{closure}} closure_annotated; const i32 i; try { a = 1; i = 1; D.137.__0 = i; _1 = test::main::{{closure}} (closure_annotated, D.137); <...> } finally { closure_annotated = {CLOBBER(eol)}; } } ``` Note this patch series does not implement the argument capture yet but this patch set is good start to the implementation so far. Addresses #195 Co-authored-by: Philip Herron <philip.herron@embecosm.com> Diff: gcc/rust/Make-lang.in | 2 + gcc/rust/ast/rust-expr.h | 9 +- gcc/rust/ast/rust-path.h | 2 + gcc/rust/backend/rust-compile-block.h | 6 +- gcc/rust/backend/rust-compile-context.h | 31 + gcc/rust/backend/rust-compile-expr.cc | 306 +++++++- gcc/rust/backend/rust-compile-expr.h | 16 +- gcc/rust/backend/rust-compile-type.cc | 10 +- gcc/rust/backend/rust-mangle.cc | 6 + gcc/rust/backend/rust-tree.h | 5 + .../checks/errors/privacy/rust-privacy-reporter.cc | 8 +- .../checks/errors/privacy/rust-privacy-reporter.h | 3 +- gcc/rust/checks/errors/rust-const-checker.cc | 10 +- gcc/rust/checks/errors/rust-const-checker.h | 3 +- gcc/rust/checks/errors/rust-unsafe-checker.cc | 10 +- gcc/rust/checks/errors/rust-unsafe-checker.h | 3 +- gcc/rust/checks/lints/rust-lint-marklive.h | 5 + gcc/rust/hir/rust-ast-lower-base.cc | 113 --- gcc/rust/hir/rust-ast-lower-base.h | 2 + gcc/rust/hir/rust-ast-lower-expr.cc | 810 +++++++++++++++++++++ gcc/rust/hir/rust-ast-lower-expr.h | 746 ++----------------- gcc/rust/hir/rust-ast-lower-pattern.cc | 18 + gcc/rust/hir/rust-ast-lower-pattern.h | 24 +- gcc/rust/hir/rust-ast-lower-type.cc | 232 ++++++ gcc/rust/hir/rust-ast-lower-type.h | 63 +- gcc/rust/hir/rust-ast-lower.cc | 23 + gcc/rust/hir/rust-hir-dump.cc | 6 +- gcc/rust/hir/rust-hir-dump.h | 3 +- gcc/rust/hir/tree/rust-hir-expr.h | 213 +++--- gcc/rust/hir/tree/rust-hir-full-decls.h | 2 - gcc/rust/hir/tree/rust-hir-full-test.cc | 37 +- gcc/rust/hir/tree/rust-hir-path.h | 68 +- gcc/rust/hir/tree/rust-hir-visitor.h | 9 +- gcc/rust/hir/tree/rust-hir.h | 1 + gcc/rust/resolve/rust-ast-resolve-expr.cc | 58 ++ gcc/rust/resolve/rust-ast-resolve-expr.h | 48 +- gcc/rust/resolve/rust-ast-resolve-type.cc | 15 +- gcc/rust/typecheck/rust-hir-type-check-expr.cc | 315 +++++++- gcc/rust/typecheck/rust-hir-type-check-expr.h | 10 +- gcc/rust/typecheck/rust-hir-type-check.h | 2 + gcc/rust/typecheck/rust-tyctx.cc | 32 + gcc/rust/typecheck/rust-tyty-bounds.cc | 69 +- gcc/rust/typecheck/rust-tyty-call.cc | 98 ++- gcc/rust/typecheck/rust-tyty-call.h | 79 +- gcc/rust/typecheck/rust-tyty-cmp.h | 23 + gcc/rust/typecheck/rust-tyty-rules.h | 40 +- gcc/rust/typecheck/rust-tyty.cc | 71 +- gcc/rust/typecheck/rust-tyty.h | 38 +- gcc/rust/util/rust-lang-item.h | 7 + gcc/testsuite/rust/execute/torture/closure1.rs | 18 + gcc/testsuite/rust/execute/torture/closure2.rs | 32 + 51 files changed, 2455 insertions(+), 1305 deletions(-)
reply other threads:[~2022-10-22 10:48 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20221022104847.146DC38582A3@sourceware.org \ --to=tschwinge@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).