Skip to content

Commit 50c8f3a

Browse files
committed
Add description of Apurva's project
The draft was bootstrapped by David Lattimore, the mentor of the project.
1 parent c575d2e commit 50c8f3a

File tree

1 file changed

+5
-1
lines changed

1 file changed

+5
-1
lines changed

posts/2024-11-01-gsoc-2024-results.md

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -128,7 +128,11 @@ TODO
128128
- Mentor: [David Lattimore](https://github.com/davidlattimore)
129129
- [Final report](https://github.com/mav3ri3k/rust/blob/gsoc24/gsoc24.md)
130130

131-
TODO
131+
Rust procedural (proc) macros are currently run as native code that gets compiled to a shared object which is loaded directly into the process of the Rust compiler. Because of this design, these macros can do whatever they want, for example arbitrarily access the filesystem or communicate through a network. This has not only obvious security implications, but it also affects performance, as this design makes it difficult to cache proc macro invocations. Over the years, there have been various discussions about making proc macros more *hermetic*, for example by compiling them to WebAssembly modules, which can be easily executed in a sandbox. This would also open the possibility of distributing precompiled versions of proc macros via crates.io, to speed up fresh builds of crates that depend on proc macros.
132+
133+
The goal of this project was to examine what would it take to implement WebAssembly module support for proc macros and create a prototype of this idea. We knew this would be a very ambitious project, especially since Apurva did not have prior experience with contributing to the Rust compiler, and because proc macro internals are very complex. Nevertheless, some progress was made. With the help of his mentor, David, Apurva was able to create a prototype that can load WebAssembly code into the compiler via a shared object. Some work was also done to make use of the existing `TokenStream` serialization and deserialization code in the compiler's `proc_macro` crate.
134+
135+
Even though this project did not fulfill its original goals and more work will be needed in the future to get a functional prototype of WebAssembly proc macros, we are thankful for Apurva's contributions. The WebAssembly loading prototype is a good start, and Apurva's exploration of proc macro internals should serve as a useful reference for anyone working on this feature in the future. Going forward, we will try to describe more incremental steps for our GSoC projects, as this project was perhaps too ambitious from the start.
132136

133137
### Tokio async support in Miri
134138

0 commit comments

Comments
 (0)