bors [Tue, 4 Oct 2016 23:30:30 +0000 (16:30 -0700)]
Auto merge of #36814 - petrochenkov:def, r=eddyb
Refactoring/bugfixing around definitions for struct/variant constructors
https://github.com/rust-lang/rust/commit/d917c364ad0edfa441e5c219da1b00511b976789 separates definitions for struct/variant constructors living in value namespace from struct/variant type definitions.
https://github.com/rust-lang/rust/commit/adfb37827b3a52a83dd11d5781e5b492714a5d4c fixes cross-crate resolution of reexports reexporting half-items, like struct constructors without struct type or types without constructor. Such reexports can appear due to glob shadowing.
Resolution now is not affected by the order in which items and reexports are decoded from metadata (cc https://github.com/rust-lang/rust/issues/31337#issuecomment-183996263). `try_define` is not used during building reduced graph anymore.
500 lines of this PR are tests for this exotic situation, the remaining line diff count is actually negative! :)
https://github.com/rust-lang/rust/commit/c695d0c8756a87c0708b97b7e277b6a3f4712b97 (and partially https://github.com/rust-lang/rust/commit/aabf132de04643602ec17b6abab9e276366d9c6d) moves most of pattern resolution checks from typeck to resolve (except those checking for associated items), uses the same wording for pattern resolution error messages from both typeck and resolve and makes the messages more precise.
https://github.com/rust-lang/rust/commit/11e3524e5afa4ac1b04aece67fb683f078e63f37 fixes seemingly incorrectly set `NON_ZERO_SIZED` attributes for struct/variant ctors in const eval.
https://github.com/rust-lang/rust/commit/4586fea2531054d9b25f8663f1ba4b32b07c11c2 eliminates `ty::VariantKind` in favor of `def::CtorKind`. The logic is that variant kinds are irrelevant for types, they make sense only when we deal with constructor functions/constants. Despite that `VariantDefData` still keeps a copy of `CtorKind`, but it's used only for various kinds of pretty-printing (and for storing in metadata).
https://github.com/rust-lang/rust/commit/aabf132de04643602ec17b6abab9e276366d9c6d is mostly a cleanup of various impossible or improperly used definitions, and other small definition cleanups.
bors [Tue, 4 Oct 2016 20:23:09 +0000 (13:23 -0700)]
Auto merge of #36933 - alexcrichton:less-neon-again, r=eddyb
rustc: Try again to disable NEON on armv7 linux
This is a follow-up to #35814 which apparently didn't disable it hard enough. It
looks like LLVM's default armv7 target enables NEON so we'd otherwise have to
pass `-neon`, but we're already enabling armv7 with `+v7` supposedly, so let's
try just telling LLVM that the armv7 target is arm and then enable features
selectively.
Alex Crichton [Mon, 3 Oct 2016 17:09:28 +0000 (10:09 -0700)]
rustc: Try again to disable NEON on armv7 linux
This is a follow-up to #35814 which apparently didn't disable it hard enough. It
looks like LLVM's default armv7 target enables NEON so we'd otherwise have to
pass `-neon`, but we're already enabling armv7 with `+v7` supposedly, so let's
try just telling LLVM that the armv7 target is arm and then enable features
selectively.
bors [Tue, 4 Oct 2016 15:29:41 +0000 (08:29 -0700)]
Auto merge of #36874 - japaric:thumbs, r=alexcrichton
add Thumbs to the compiler
this commit adds 4 new target definitions to the compiler for easier
cross compilation to ARM Cortex-M devices.
- `thumbv6m-none-eabi`
- For the Cortex-M0, Cortex-M0+ and Cortex-M1
- This architecture doesn't have hardware support (instructions) for
atomics. Hence, the `Atomic*` structs are not available for this
target.
- `thumbv7m-none-eabi`
- For the Cortex-M3
- `thumbv7em-none-eabi`
- For the FPU-less variants of the Cortex-M4 and Cortex-M7
- On this target, all the floating point operations will be lowered
software routines (intrinsics)
- `thumbv7em-none-eabihf`
- For the variants of the Cortex-M4 and Cortex-M7 that do have a FPU.
- On this target, all the floating point operations will be lowered
to hardware instructions
No binary releases of standard crates, like `core`, are planned for
these targets because Cargo, in the future, will compile e.g. the `core`
crate on the fly as part of the `cargo build` process. In the meantime,
you'll have to compile the `core` crate yourself. [Xargo] is the easiest
way to do that as in handles the compilation of `core` automatically and
can be used just like Cargo: `xargo build --target thumbv6m-none-eabi`
is all that's needed.
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 [Tue, 4 Oct 2016 02:36:27 +0000 (19:36 -0700)]
Auto merge of #36876 - nikomatsakis:issue-36381, r=pnkfelix
loosen assertion against proj in collector
The collector was asserting a total absence of projections, but some projections are expected, even in trans: in particular, projections containing higher-ranked regions, which we don't currently normalize.
Niko Matsakis [Fri, 30 Sep 2016 22:15:11 +0000 (18:15 -0400)]
loosen assertion against proj in collector
The collector was asserting a total absence of projections, but some
projections are expected, even in trans: in particular, projections
containing higher-ranked regions, which we don't currently normalize.
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.
this commit adds 4 new target definitions to the compiler for easier
cross compilation to ARM Cortex-M devices.
- `thumbv6m-none-eabi`
- For the Cortex-M0, Cortex-M0+ and Cortex-M1
- This architecture doesn't have hardware support (instructions) for
atomics. Hence, the `Atomic*` structs are not available for this
target.
- `thumbv7m-none-eabi`
- For the Cortex-M3
- `thumbv7em-none-eabi`
- For the FPU-less variants of the Cortex-M4 and Cortex-M7
- On this target, all the floating point operations will be lowered
software routines (intrinsics)
- `thumbv7em-none-eabihf`
- For the variants of the Cortex-M4 and Cortex-M7 that do have a FPU.
- On this target, all the floating point operations will be lowered
to hardware instructions
No binary releases of standard crates, like `core`, are planned for
these targets because Cargo, in the future, will compile e.g. the `core`
crate on the fly as part of the `cargo build` process. In the meantime,
you'll have to compile the `core` crate yourself. [Xargo] is the easiest
way to do that as in handles the compilation of `core` automatically and
can be used just like Cargo: `xargo build --target thumbv6m-none-eabi`
is all that's needed.
projects / rust.git / log