At the moment, when compilation is stopped at a stop point (like `-Z parse-only`), `rustc` does not return an nonzero exit code even if there are errors (expect fatal ones, that cause it to panic immediately). As an example, compiling `src/test/compile-fail/doc-before-semi.rs` with `-Z parse-only` raises an error, but exists with 0.
Note that I could not use `sess.abort_if_errors()` in the macro, because `sess` is passed by value and move at some point.
skolemize_late_bound_regions essentially copies the entire type (most of the times it shouldn't, but it does), and match_impl runs millions of times.
Times compiling rustc, tested with
$ make -j4 rustc-stage1
$ ( time RUSTFLAGS=-Z time-passes make -j4 rustc-stage2 ) # need LLVM time for calibration
Before:
real 21m44.960s
user 29m38.812s
sys 0m14.944s
After:
real 19m31.445s
user 26m47.260s
sys 0m14.952s
Making this is a 10% performance improvement.
LLVM passes took 867 seconds before, 862 seconds after.
This implementation is currently about 3-4 times faster than using the `.to_string()` based approach.
I would also suggest we deprecate `String::from_str` since it's redundant with the stable `String::from` method, but I'll leave that for a future PR.
"Dynamically typed" didn't seem like a relevant distinction; there are statically-compiled dynamically-typed languages. Another term that might work here (despite being notoriously vague) is "scripting languages".
Apply optimization described in
https://github.com/rust-lang/regex/pull/73#issuecomment-93777126
to rust's copy of `unicode.py`.
This shrinks librustc_unicode's tables.rs from 479kB to 456kB,
and should improve performance slightly for related operations
(e.g., is_alphabetic(), is_xid_start(), etc).
In addition, pull in fix from @dscorbett's commit
d25c39f86568a147f9b7080c25711fb1f98f056a in regex, which
makes `load_properties()` more tolerant of whitespace
in the Unicode tables. (This fix does not result in any
changes to tables.rs, but could if the Unicode tables
change in the future.)
This just deletes some egregious lies and obsolete terminology -- all of which I originally wrote -- from the reference. I expect the reference itself will be deleted soon enough, but I found myself gritting teeth over these bits too much to let them into a 1.0 release.
