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
Reviving rust-chamber in 2023 #1
Comments
The main thing chamber did was add custom lints to the compiler. It may be possible to do this with https://github.com/trailofbits/dylint now, and then just run the compiler as normal, where chamber actually used the compiler as a library. If dylint isn't powerful enough to reject everything chamber needs to, then it appears that the same basic It's still probably possible to write a custom compiler driver that uses rustc as a library, though rustc internals have completely changed. What existed of chamber, just a prototype really, is a tiny amount of code, so it should be feasible to rewrite it from scratch following essentially the same strategy - use rustc as a library, load a custom plugin through the unsupported internal plugin api. It probably wouldn't take more than a day to prove the concept again. |
Also, since the mechanism to link to other crates has changed, and is no longer syntactic ( |
Thanks for the advice! As for using linter instead of a compiler plugin, that does sound rather interesting. I suppose one could enforce the filtering on use statements, and from that ensure the sandbox is tight. Though re-exports will be tricky to keep under control (as the same thing may get reexported under a different name from a different crate. I'll need to dig into dylint then =) |
Hi! I've found this project to be super interesting as a candidate for scripting engine in a game. However, it was built long ago in a galaxy far far away. In your estimate, what would it take to make it work with modern rustc?
The text was updated successfully, but these errors were encountered: