I preemptively opened this because I have a couple questions:

1. How should tests be structured/organized for compiler plugins?
2. Should the url crate depend on url_plugin? Wouldn't that create a cyclic dependency?

To answer questions:

1. I don’t think many tests are needed here, one to check that the plugin doesn’t panic and returns something sensible should be enough. It’d have to be in a separate crate so you can use the plugin. Cargo will compile a separate crate (run a separate rustc --test invocation) if you have a file named e.g. plugin/tests/smoke_test.rs, so you don’t need another Cargo.toml file.
2. No it shouldn’t, why? Yes it would.

The code looks ok but (sorry I didn’t mention this earlier) I wonder if this plugin should be here rather than in Servo. We can move it back if someone asks, but in the meantime I don’t know if anyone else would use it. Meanwhile, this code uses unstable compiler internals (as plugins do) and rust-url is sort of expected to work on Rust Nightly, while Rust-in-Servo is updated less frequently.

To put it more bluntly, moving it to Servo is likely less future work for me :]

I wonder if this plugin should be here rather than in Servo

We don't need to ship this crate as part of rust-url. It can be published separately and used only by Servo.

I’m suggesting having this in the servo/servo repository rather than this one, where the Rust version used on CI is updated less frequently. This is not about publishing on crates.io.

Suggestions on where it should live in Servo?

The plugins crate?

servo/servo#8622

The url! macro for compile-time validation is now available via url-macro crate.

Disclaimer: I'm the author.