Skip to content
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

Open
alexpyattaev opened this issue Oct 3, 2023 · 3 comments
Open

Reviving rust-chamber in 2023 #1

alexpyattaev opened this issue Oct 3, 2023 · 3 comments

Comments

@alexpyattaev
Copy link

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?

@brson
Copy link
Owner

brson commented Oct 4, 2023

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 plugin_registrar mechanism continues to exist inside rustc, though I gather it is unsupported and will never be stabilized, will be removed someday.

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.

@brson
Copy link
Owner

brson commented Oct 4, 2023

Also, since the mechanism to link to other crates has changed, and is no longer syntactic (extern crate), some other mechanism besides lints needs to be used to reject linkage.

@alexpyattaev
Copy link
Author

Thanks for the advice!
As for rejecting linkage that is fairly easy as long as the project's Cargo.toml is controlled. In this case any crate not mentioned there would simply fail to import. I'd expect that any sandboxing effort would control Cargo.toml and build.rs first and foremost. Or am I missing an obvious problem with that?

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 =)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants