Rollup merge of #36921 - nnethercote:two-lexer-tweaks, r=nrc
Two lexer tweaks
19 days later, I haven't received a review of my commits in #36470. In an attempt to make some progress, I'm going to split up the changes. Here are the ones that don't relate to renaming things.
Rollup merge of #36917 - nnethercote:speed-up-plug_leaks, r=eddyb
Speed up `plug_leaks`
Profiling shows that `plug_leaks` and the functions it calls are hot on some benchmarks. It's very common that `skol_map` is empty in this function, and we can specialize `plug_leaks` in that case for some big speed-ups.
The PR has two commits. I'm fairly confident that the first one is correct -- I traced through the code to confirm that the `fold_regions` and `pop_skolemized` calls are no-ops when `skol_map` is empty, and I also temporarily added an assertion to check that `result` ends up having the same value as `value` in that case. This commit is responsible for most of the improvement.
I'm less confident about the second commit. The call to `resolve_type_vars_is_possible` can change `value` when `skol_map` is empty... but testing suggests that it doesn't matter if the call is
omitted.
So, please check both patches carefully, especially the second one!
Here are the speed-ups for the first commit alone.
stage1 compiler (built with old rustc, using glibc malloc), doing debug builds:
```
futures-rs-test 4.710s vs 4.538s --> 1.038x faster (variance: 1.009x, 1.005x)
issue-32062-equ 0.415s vs 0.368s --> 1.129x faster (variance: 1.009x, 1.010x)
issue-32278-big 1.884s vs 1.808s --> 1.042x faster (variance: 1.020x, 1.017x)
jld-day15-parse 1.907s vs 1.668s --> 1.143x faster (variance: 1.011x, 1.007x)
piston-image-0. 13.024s vs 12.421s --> 1.049x faster (variance: 1.004x, 1.012x)
rust-encoding-0 3.335s vs 3.276s --> 1.018x faster (variance: 1.021x, 1.028x)
```
stage2 compiler (built with new rustc, using jemalloc), doing debug builds:
```
futures-rs-test 4.167s vs 4.065s --> 1.025x faster (variance: 1.006x, 1.018x)
issue-32062-equ 0.383s vs 0.343s --> 1.118x faster (variance: 1.012x, 1.016x)
issue-32278-big 1.680s vs 1.621s --> 1.036x faster (variance: 1.007x, 1.007x)
jld-day15-parse 1.671s vs 1.478s --> 1.131x faster (variance: 1.016x, 1.004x)
piston-image-0. 11.336s vs 10.852s --> 1.045x faster (variance: 1.003x, 1.006x)
rust-encoding-0 3.036s vs 2.971s --> 1.022x faster (variance: 1.030x, 1.032x)
```
I've omitted the benchmarks for which the change was negligible.
And here are the speed-ups for the first and second commit in combination.
stage1 compiler (built with old rustc, using glibc malloc), doing debug
builds:
```
futures-rs-test 4.684s vs 4.498s --> 1.041x faster (variance: 1.012x, 1.012x)
issue-32062-equ 0.413s vs 0.355s --> 1.162x faster (variance: 1.019x, 1.006x)
issue-32278-big 1.869s vs 1.763s --> 1.060x faster (variance: 1.013x, 1.018x)
jld-day15-parse 1.900s vs 1.602s --> 1.186x faster (variance: 1.010x, 1.003x)
piston-image-0. 12.907s vs 12.352s --> 1.045x faster (variance: 1.005x, 1.006x)
rust-encoding-0 3.254s vs 3.248s --> 1.002x faster (variance: 1.063x, 1.045x)
```
stage2 compiler (built with new rustc, using jemalloc), doing debug builds:
```
futures-rs-test 4.183s vs 4.046s --> 1.034x faster (variance: 1.007x, 1.004x)
issue-32062-equ 0.380s vs 0.340s --> 1.117x faster (variance: 1.020x, 1.003x)
issue-32278-big 1.671s vs 1.616s --> 1.034x faster (variance: 1.031x, 1.012x)
jld-day15-parse 1.661s vs 1.417s --> 1.172x faster (variance: 1.013x, 1.005x)
piston-image-0. 11.347s vs 10.841s --> 1.047x faster (variance: 1.007x, 1.010x)
rust-encoding-0 3.050s vs 3.000s --> 1.017x faster (variance: 1.016x, 1.012x)
```
@eddyb: `git blame` suggests that you should review this. Thanks!
Rollup merge of #36878 - BlueSpaceCanary:book-dedup-cargo-run-intro, r=GuillaumeGomez
Avoid introducing `run` twice in the Rust book
As it stands, getting-started.md and guessing-game.md both introduce `run` as a new command. I switched it so that the 2nd refers back to the first introduction, rather than re-introducing the command.
(First ever FOSS PR, sorry if I screwed up anything obvious :) )
Rollup merge of #36798 - gavinb:fix/36164, r=GuillaumeGomez
Improve error message and snippet for "did you mean `x`"
- Fixes #36164
- Part of #35233
Based on the standalone example https://is.gd/8STXMd posted by @nikomatsakis and using the third formatting option mentioned in #36164 and agreed by @jonathandturner.
Note however this does not address the question of [how to handle an empty or unknown suggestion](https://github.com/rust-lang/rust/issues/36164#issuecomment-244460024). @nikomatsakis any suggestions on how best to address that part?
bors [Mon, 3 Oct 2016 14:40:22 +0000 (07:40 -0700)]
Auto merge of #36847 - alexcrichton:rustc-macro-doc, r=nrc
rustdoc: Fix documenting rustc-macro crates
This commit adds a "hack" to the session to track whether we're a rustdoc
session or not. If we're rustdoc then we skip the expansion to add the
rustc-macro infrastructure.
bors [Mon, 3 Oct 2016 11:25:58 +0000 (04:25 -0700)]
Auto merge of #36766 - nnethercote:hash-span-capacity, r=bluss
Clarify HashMap's capacity handling.
HashMap has two notions of "capacity":
- "Usable capacity": the number of elements a hash map can hold without
resizing. This is the meaning of "capacity" used in HashMap's API,
e.g. the `with_capacity()` function.
- "Internal capacity": the number of allocated slots. Except for the
zero case, it is always larger than the usable capacity (because some
slots must be left empty) and is always a power of two.
HashMap's code is confusing because it does a poor job of
distinguishing these two meanings. I propose using two different terms
for these two concepts. Because "capacity" is already used in HashMap's
API to mean "usable capacity", I will use a different word for "internal
capacity". I propose "span", though I'm happy to consider other names.
bors [Mon, 3 Oct 2016 08:30:32 +0000 (01:30 -0700)]
Auto merge of #36767 - jseyfried:enforce_rfc_1560_shadowing, r=nrc
Enforce the shadowing restrictions from RFC 1560 for today's macros
This PR enforces a weakened version of the shadowing restrictions from RFC 1560. More specifically,
- If a macro expansion contains a `macro_rules!` macro definition that is used outside of the expansion, the defined macro may not shadow an existing macro.
- If a macro expansion contains a `#[macro_use] extern crate` macro import that is used outside of the expansion, the imported macro may not shadow an existing macro.
This is a [breaking-change]. For example,
```rust
macro_rules! m { () => {} }
macro_rules! n { () => {
macro_rules! m { () => {} } //< This shadows an existing macro.
m!(); //< This is inside the expansion that generated `m`'s definition, so it is OK.
} }
n!();
m!(); //< This use of `m` is outside the expansion, so it causes the shadowing to be an error.
```
Simplify `start_bpos` calculation in scan_comment().
The two branches of this `if` compute the same value. This commit gets
rid of the first branch, which makes this calculation identical to the
one in scan_block_comment().
First, assert! is redundant w.r.t. the unwrap() immediately afterwards.
Second, `byte_offset_diff` is effectively computed as
`current_byte_offset + ch.len_utf8() - current_byte_offset` (with `next`
as an intermediate) which is silly and can be simplified.
This commit avoids the `resolve_type_vars_if_possible` call in
`plug_leaks` when `skol_map` is empty, which is the common case. It also
changes the signature of `plug_leaks` slightly to avoid the need for a
`clone` of `value`. These changes give speed-ups of up a few percent on
some of the rustc-benchmarks.
This commit avoids the `fold_regions` call in `plug_leaks` when
`skol_map` is empty, which is the common case. This gives speed-ups of
up to 1.14x on some of the rustc-benchmarks.
bors [Mon, 3 Oct 2016 00:33:34 +0000 (17:33 -0700)]
Auto merge of #36807 - brson:pal, r=brson
Restrict where in the tree platform-specific cfgs may be mentioned
With the ports of Rust never ending, it's important that we keep things tidy. The main thing this PR does is introduce a new "pal" (platform abstraction layer) tidy check that limits where platform-specific CFGs may appear.
This is intended to maintain existing standards of code organization
in hopes that the standard library will continue to be refactored to
isolate platform-specific bits, making porting easier; where "standard
library" roughly means "all the dependencies of the std and test
crates".
This generally means placing restrictions on where `cfg(unix)`,
`cfg(windows)`, `cfg(target_os)` and `cfg(target_env)` may appear,
the basic objective being to isolate platform-specific code to the
platform-specific `std::sys` modules, and to the allocation,
unwinding, and libc crates.
Following are the basic rules, though there are currently
exceptions:
- core may not have platform-specific code
- liballoc_system may have platform-specific code
- liballoc_jemalloc may have platform-specific code
- libpanic_abort may have platform-specific code
- libpanic_unwind may have platform-specific code
- other crates in the std facade may not
- std may have platform-specific code in the following places
- sys/unix/
- sys/windows/
- os/
There are plenty of exceptions today though, noted in the whitelist.
The end-state, IMO, is for the standard library to be portable by porting only `std::sys` (possibly extracted to its own crate), an allocator crate, an unwinder crate, and possibly a libc crate (if std depends on it); but that outcome is far off and independent of the utility of enforcing where such code lives today.
Philip Davis [Fri, 30 Sep 2016 22:13:20 +0000 (15:13 -0700)]
Avoid introducing `run` twice
As it stands, getting-started and guessing-game both introduce `run` as
a new command. The second should probably make it clear that the reader
has seen it before :)
Brian Anderson [Thu, 22 Sep 2016 01:30:30 +0000 (01:30 +0000)]
Add a platform-abstraction tidy script
This is intended to maintain existing standards of code organization
in hopes that the standard library will continue to be refactored to
isolate platform-specific bits, making porting easier; where "standard
library" roughly means "all the dependencies of the std and test
crates".
This generally means placing restrictions on where `cfg(unix)`,
`cfg(windows)`, `cfg(target_os)` and `cfg(target_env)` may appear,
the basic objective being to isolate platform-specific code to the
platform-specific `std::sys` modules, and to the allocation,
unwinding, and libc crates.
Following are the basic rules, though there are currently
exceptions:
- core may not have platform-specific code
- liballoc_system may have platform-specific code
- liballoc_jemalloc may have platform-specific code
- libpanic_abort may have platform-specific code
- libpanic_unwind may have platform-specific code
- other crates in the std facade may not
- std may have platform-specific code in the following places
- sys/unix/
- sys/windows/
- os/
There are plenty of exceptions today though, noted in the whitelist.
bors [Sun, 2 Oct 2016 21:13:27 +0000 (14:13 -0700)]
Auto merge of #36904 - camlorn:field_offsets_refactor, r=eddyb
Refactor layout to store offsets of fields, not offsets after fields
This is the next PR moving us towards being able to reorder struct fields.
The old code implicitly stored the offset of the first field. This is inadequate because the first field may no longer be offset 0 in future. This PR refactors `layout` to use a `offsets` vector instead of a `offset_after_field` vector.
Rollup merge of #35874 - CensoredUsername:stmt_let_typed_fix, r=Manishearth
This commit makes the return type of AstBuilder.stmt_let_typed match the return type of other AstBuilder.stmt* functions. This avoids unnecessary boxing/unboxing whenever Stmt's are stored in a Vec, which is the default use case.nnThis is a potentially plugin breaking change.
Rollup merge of #36877 - solson:rustc-version-build-issue, r=eddyb
Fix RUSTC_VERSION for 'documenting' build stage.
Previously the `env!("RUSTC_VERSION")` requirement would break the "Documenting rustc_metadata" stage of the rustc build, since that environment variable is only defined during the main build.
bors [Sat, 1 Oct 2016 02:00:36 +0000 (19:00 -0700)]
Auto merge of #36339 - brson:emscripten-new, r=alexcrichton
Working asmjs and wasm targets
This patch set results in a working standard library for the asmjs-unknown-emscripten and wasm32-unknown-emscripten targets. It is based on the work of @badboy and @rschulman.
It does a few things:
- Updates LLVM with the emscripten [fastcomp](https://github.com/rust-lang/llvm/pull/50) patches, which include the pnacl IR legalizer and the asm.js backend. This patch is thought not to have any significant effect on existing targets.
- Teaches rustbuild to correctly link C code with emscripten
- Updates gcc-rs to work correctly with emscripten
- Teaches rustbuild to run crate tests for emscripten with node
- Modifies Thread::new to return an error on emscripten, to facilitate debugging a common failure mode
- Modifies libtest to run in single-threaded mode for emscripten
- Ignores a host of tests that don't work yet, mostly dealing with threads and I/O
- Updates libc with wasm32 definitions (presently the same as asmjs)
- Adds a wasm32-unknown-emscripten target that feeds the output of LLVM's asmjs backend through emcc to generate wasm
Notes and caveats:
- This is only known to work with `--enable-rustbuild`.
- The wasm32 target can't be tested correctly yet because of issues in compiletest and limitations in node https://github.com/kripken/emscripten/issues/4542, but hello.rs does seem to work when run on node via the binaryen interpreter
- This requires an up to date installation of the emscripten sdk from its incoming branch
- Unwinding is very broken
- When enabling the emscripten targets jemalloc is disabled for all targets, which results in test failures for the host
Next steps are to fix the jemalloc issue, start building the two emscripten targets on the auto builders, then start producing nightlies.
https://github.com/rust-lang/rust/issues/36317 tracks work on this.
Auto merge of #36866 - alexcrichton:fix-hash-again, r=eddyb
rustc: More fixes for arch-independent hashing
In another attempt to fix #36793 this commit attempts to head off any future
problems by adding a custom `WidentUsizeHasher` which will widen any hashing of
`isize` and `usize` to a `u64` as necessary. This obviates the need for a
previous number of `as u64` annotations and will hopefully protect us against
future problems here.
Scott Olson [Fri, 30 Sep 2016 22:24:50 +0000 (16:24 -0600)]
Fix RUSTC_VERSION for 'documenting' build stage.
Previously the `env!("RUSTC_VERSION")` requirement would break the
"Documenting rustc_metadata" stage of the rustc build, since that
environment variable is only defined during the main build.
Alex Crichton [Fri, 30 Sep 2016 18:06:51 +0000 (11:06 -0700)]
rustc: More fixes for arch-independent hashing
In another attempt to fix #36793 this commit attempts to head off any future
problems by adding a custom `WidentUsizeHasher` which will widen any hashing of
`isize` and `usize` to a `u64` as necessary. This obviates the need for a
previous number of `as u64` annotations and will hopefully protect us against
future problems here.
Brian Anderson [Tue, 27 Sep 2016 21:27:22 +0000 (21:27 +0000)]
Build a dummy alloc_jemalloc crate on platforms that don't support it
This is a hack to support building targets that don't support jemalloc
alongside hosts that do. The jemalloc build is controlled by a feature
of the std crate, and if that feature changes between targets, it
invalidates the fingerprint of std's build script (this is a cargo
bug); so we must ensure that the feature set used by std is the same
across all targets, which means we have to build the alloc_jemalloc
crate for targets like emscripten, even if we don't use it.
projects / rust.git / log