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 #1362 Date: Fri, 15 Jul 2022 21:38:22 +0000 (GMT) [thread overview] Message-ID: <20220715213822.63E573858406@sourceware.org> (raw) https://gcc.gnu.org/g:fd2bd659e44e5b7fea92bc34a4864f057f387490 commit fd2bd659e44e5b7fea92bc34a4864f057f387490 Merge: 67f9b173b90 2d1378f7310 Author: bors[bot] <26634292+bors[bot]@users.noreply.github.com> Date: Fri Jul 15 16:09:43 2022 +0000 Merge #1362 1362: extern crate loading r=philberty a=philberty WIP still trying to write dejagnu to enable automated tests Extern crates statements to tell the front-end to look for another library. The mechanism here is heavily inspired from gccgo, so when we compile a library for example we invoke: ``` gccrs -g -O2 -frust-crate=mylib -c src/lib.rs -o src/mylib.o ``` All going well this object file will now contain extra data inside .rust-export section inside the object file which will be preserved inside archives and shared objects. When we have another application which uses this library 'mylib'. ```rust extern crate mylib; use mylib::foo; fn main() { foo(); } ``` We compile using: ``` gcc -g -O2 -frust-crate=test -c src/main.rs -o src/main.o ``` When the extern crate line is hit the front-end will look for mylib.o, libmylib.a, mylib.rox. If it finds a raw object file it will read the .rust-export section directly from the object for the public metadata such as public functions, types constants etc. If it fails to find an object it might find .rox which is the objdump of the .rust-export to a raw file, it might even find libmylib.a and read the export directly out of the archive file reusing code from gccgo to do so. The full compiler pipeline is reused here, so the metatadata is actually just real rust code. The benifit here is that Rust supports exporting, macros and generics so this requires the name-resolution and type info all to be generated and inserted into the apropriate context classes. Since the metadata is real rust code it means we can reuse the full pipeline to generate the code as nessecary. So for the simple case of a public struct we simply emit the AST dump of this struct directly into the metadata. If its a non-generic public function we emit and extern rust abi block for that function. If its a trait we can simply emit the trait with the public memebers. Generics are more complicated since we need to emit the function fully for it to be compiled correctly this still needs tests to be added. The hardest part is non generic impl blocks which is still a WIP. To finally link the two crates together you run: ``` gcc -g -O2 -o rust-program.exe src/main.o src/mylib.o ``` Fixes: 1169 Co-authored-by: Philip Herron <philip.herron@embecosm.com> Diff: gcc/rust/Make-lang.in | 12 +- gcc/rust/ast/rust-ast-dump.cc | 69 +- gcc/rust/ast/rust-ast-dump.h | 1 + gcc/rust/expand/rust-attribute-visitor.cc | 17 +- gcc/rust/lang.opt | 8 + gcc/rust/metadata/rust-export-metadata.cc | 385 +++++++++++ gcc/rust/metadata/rust-export-metadata.h | 85 +++ gcc/rust/metadata/rust-extern-crate.cc | 173 +++++ gcc/rust/metadata/rust-extern-crate.h | 55 ++ gcc/rust/metadata/rust-import-archive.cc | 885 ++++++++++++++++++++++++++ gcc/rust/metadata/rust-imports.cc | 441 +++++++++++++ gcc/rust/metadata/rust-imports.h | 257 ++++++++ gcc/rust/resolve/rust-ast-resolve-toplevel.h | 60 +- gcc/rust/rust-object-export.cc | 6 - gcc/rust/rust-session-manager.cc | 110 +++- gcc/rust/rust-session-manager.h | 19 +- gcc/testsuite/rust/link/generic_function_0.rs | 7 + gcc/testsuite/rust/link/generic_function_1.rs | 3 + gcc/testsuite/rust/link/link.exp | 163 +++++ gcc/testsuite/rust/link/simple_function_0.rs | 7 + gcc/testsuite/rust/link/simple_function_1.rs | 3 + gcc/testsuite/rust/link/trait_import_0.rs | 19 + gcc/testsuite/rust/link/trait_import_1.rs | 6 + 23 files changed, 2740 insertions(+), 51 deletions(-)
reply other threads:[~2022-07-15 21:38 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=20220715213822.63E573858406@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).