rustpkg compatibility

[haxney]

Right now, there are two main things preventing easy use with rustpkg:

• Generation of color_data.rs
• non-standard naming of tests.rs

Both are pretty straightforward and the second can be done with minimal
modifications:

• rename tests.rs to test.rs

• remove the following from lib.rs

  #[cfg(test)]
  mod tests;
  

• Add extern mod extra; and the use and mod lines from lib.rs to the
  beginning of test.rs.

I'm not sure of an easy solution to generating color_data.rs (aside from
simply skipping the generation step entirely).

[SimonSapin]

About testing: if tests are in a separate crate, is the lib crate never built with cfg(test)? That may be a problem for tokenizer.rs as I have one test there for a private function, and an assert (and associated counting) that is only active when testing.

As to color_data.rs, this is IMO a defect of rustpkg. As long as we don’t have syntax extensions, macros are not powerful enough and we need another way to generate Rust code by running arbitrary code at compile-time. Servo has to other cases of this. (DOM bindings in the script crate, and properties.rs.mako in the style crate.)

[haxney]

I'm no expert on rustpkg, so I don't know the answer to the first question off
the top of my head. Probably worth asking the author or on #rust.

As for the second point, it is probably possible to get rustpkg to build the
file if you supply a custom pkg.rs file. See here for info on custom build scripts. I don't have any experience writing custom
build scripts, so I don't know how easy this is.

[SimonSapin]

cfg(test) stuff in the tokenizer should be replaced with debug_assert!().

With #32, there is no generated file anymore.

It should now be easier to make rust-cssparser work with rustpkg. I’d review a pull request doing so.

[SimonSapin]

Closing due to rust-lang/rust#11987