In terms of "same crate" macros, there was a proposal to use the same package for proc macros to eliminate separate *_derive crates, and build them the same way build.rs is:
Of course that's orthogonal to the security issue.
4 Likes
We could have the proc macros compile to wasm if a specific flag is specified (--wasm-macros?) . Then, all "unimplemened" functions in std would raise a special type of panic. IDEs could then pass --wasm-macros by default, and if the build fails because of an unimplemened wasm std function - prompt the user for permissions (perhaps listing the dependency ancestry of the crate whose compilation failed). If a more sophisticated sandbox is implemented (for example, allowing fs read access to the workspace), the same fallback strategy can still be used.
How well this can work depends on how many popular crates need resources outside of the sandbox. But I think that this helps deal with the issue of left-pad needing network access.
4 Likes
I don't think const fns can adequately replace proc macros. You may, for example, want to write part of the project in a DSL that would be transpiled into rust and have that part in separate files, which would require you to have access to file IO.
As I've mentioned a couple of times now, you can still do that via include_bytes! and include_str!
That's probably not a good idea, if you have to parse a lot of stuff. Though I'll admit I can't imagine a case where the developer would need to parse a large number of files before the software can be compiled. Still, since this does not solve the build.rs problem, it seems like a half-measure.
Expanding proc macros is pretty important for IDEs to be able to comprehend code. I'd argue that there are a lot more crates that rely on proc macros than they do build.rs generating code.
2 Likes
For what it's worth, many of the most-used libraries on crates.io have build scripts, including:
- log
- syn
- libc
- proc-macro2
- serde
- num-traits
Some relatively self-contained crates can be checked without running any build scripts, but I expect that a very large proportion of Rust projects depend on one of these, or on some other crate with a build script.
Notably, almost all crates that use proc macros have syn and/or proc-macro2 in their dependency graphs, which means they also depend indirectly on build scripts, at least for now.
1 Like
As it were, none of those crates (at least in their current form) would be helpful in the context of a const fn macro system as they are not implemented in terms of const fn.
I think that the goal is to minimize the proc macros and build.rs scripts that need to be audited. An entire tree of crates depending on lets say serde doesn't imply you need to look for compile time shenanigans in those crates if they don't use either proc macros or build.rs.
3 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.