Thank you all for your suggestions. Asserting on differences sounds good, and I think we can annotate the crash report with a sanitized URL as well (replace all of the alfanumerical characters with x?). Also running a crawler on top250 should iron out most kinks.
The plan is to land this preffed off, and only build the module if the rust compiler is available on the system. As Gregory pointed out, it would be better if the new implementation was as close as possible as the current Gecko parser, so we avoid any regressions. The main goal here is to make our parser safer with little behaviour differences. On 1 May 2015 at 20:58, Gregory Szorc <g...@mozilla.com> wrote: > On Thu, Apr 30, 2015 at 3:34 PM, Valentin Gosu <valentin.g...@gmail.com> > wrote: > >> As some of you may know, Rust is approaching its 1.0 release in a couple >> of >> weeks. One of the major goals for Rust is using a rust library in Gecko. >> The specific one I'm working at the moment is adding rust-url as a safer >> alternative to nsStandardURL. >> >> This project is still in its infancy, but we're making good progress. A >> WIP >> patch is posted in bug 1151899, while infrastructure support for the rust >> compiler is tracked in bug 1135640. >> >> One of the main problems in this endeavor is compatibility. It would be >> best if this change wouldn't introduce any changes in the way we parse and >> encode/decode URLs, however rust-url does differ a bit from Gecko's own >> parser. While we can account for the differences we know of, there may be >> a >> lot of other cases we are not aware of. I propose using our volunteer base >> in trying to find more of these differences by reporting them on Nightly. >> >> My patch currently uses printf to note when a parsing difference occurs, >> or >> when any of the getters (GetHost, GetPath, etc) returns a string that's >> different from our native implementation. Printf might not be the best way >> of logging these differences though. NSPR logging might work, or even >> writing to a log file in the current directory. >> >> These differences are quite privacy sensitive, so an automatic reporting >> tool probably wouldn't work. Has anyone done something like this before? >> Would fuzzing be a good way of finding more cases? >> >> I'm waiting for any comments and suggestions you may have. >> Thanks! >> > > Shipping *any* Rust component as part of Gecko is already going to be a > long and arduous task. I think it makes sense for the first Rust component > in Gecko to be a drop-in, behavior identical replacement. i.e. don't bloat > scope to include behavior changes that could jeopardize the deliverable. It > would be really unfortunate if we did all this Rust preparation work only > to have the feature utilizing it backed out because of behavior differences. > > But this is a very high-level observation. I know others spent a lot of > time figuring out what to Rust-ify first and URL parsing was eventually > chosen. If you say it is the least risky part of Gecko to swap out, I trust > that assessment. > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
