Alex Crichton [Wed, 15 Mar 2017 14:35:35 +0000 (07:35 -0700)]
appveyor: Use Ninja to build LLVM on MinGW
I have a suspicion that MinGW's make is the cause of #40546 rather than anything
else, but that's purely a suspicion without any facts to back it up. In any case
we'll eventually be moving the MSVC build over to Ninja in order to leverage
sccache regardless, so this commit simply jumpstarts that process by downloading
Ninja for use by MinGW anyway.
I'm not sure if this closes #40546 for real, but this is my current best shot at
closing it out, so...
bors [Wed, 22 Mar 2017 02:00:16 +0000 (02:00 +0000)]
Auto merge of #40043 - petrochenkov:objpars, r=nikomatsakis
Refactor parsing of trait object types
Bugs are fixed and code is cleaned up.
User visible changes:
- `ty` matcher in macros accepts trait object types like `Write + Send` (https://github.com/rust-lang/rust/issues/39080)
- Buggy priority of `+` in trait object types starting with `for` is fixed (https://github.com/rust-lang/rust/issues/39317). `&for<'a> Trait<'a> + Send` is now parsed as `(&for<'a> Trait<'a>) + Send` and requires parens `&(for<'a> Trait<'a> + Send)`. For comparison, `&Send + for<'a> Trait<'a>` was parsed like this since [Nov 27, 2014](https://github.com/rust-lang/rust/pull/19298).
- Trailing `+`s are supported in trait objects, like in other bounds.
- Better error reporting for trait objects starting with `?Sized`.
Fixes https://github.com/rust-lang/rust/issues/39080
Fixes https://github.com/rust-lang/rust/issues/39317 [breaking-change]
Closes https://github.com/rust-lang/rust/issues/39298
cc https://github.com/rust-lang/rust/issues/39085 (fixed, then reverted https://github.com/rust-lang/rust/pull/40043#issuecomment-286570653)
cc https://github.com/rust-lang/rust/issues/39318 (fixed, then reverted https://github.com/rust-lang/rust/pull/40043#issuecomment-284493890)
Manuel [Tue, 21 Mar 2017 21:18:52 +0000 (22:18 +0100)]
Fix doc error for ExactSizeIterator
The code example in the trait documentation of ExactSizeIterator
has an incorrect implementation of the len method that does not return
the number of times the example iterator 'Counter' will iterate. This
may confuse readers of the docs as the example code will compile but
doesn't uphold the trait's contract.
This is easily fixed by modifying the implementation of len and changing
the assert statement to actually assert the correct behaviour. I also
slightly modified a code comment to better reflect what the method
returns.
Alex Crichton [Fri, 17 Mar 2017 16:31:28 +0000 (09:31 -0700)]
travis: Add timestamps to all build messages
When debugging why builds are taking so long it's often useful to get the
timestamp of all log messages as we're not always timing every tiny step of the
build. I wrote a [utility] for prepending a relative timestamp from the start of
a process which is now downloaded to the builders and is what we wrap the entire
build invocation in.
Alex Crichton [Wed, 15 Mar 2017 15:09:59 +0000 (08:09 -0700)]
rustc: Always emit the `uwtable` attribute on Windows
This commit alters the translation layer to unconditionally emit the `uwtable`
LLVM attribute on Windows regardless of the `no_landing_pads` setting.
Previously I believe we omitted this attribute as an optimization when the
`-Cpanic=abort` flag was passed, but this unfortunately caused problems for
Gecko.
It [was discovered] that there was trouble unwinding through Rust functions due
to foreign exceptions such as illegal instructions or otherwise in-practice
methods used to abort a process. In testing it looked like the major difference
between a working binary and a non-working binary is indeed this `uwtable`
attribute, but this PR has unfortunately not been thoroughly tested in terms of
compiling Gecko with `-C panic=abort` *and* this PR to see whether it works, so
this is still somewhat working on just suspicion.
Jeffrey Seyfried [Tue, 14 Mar 2017 05:16:54 +0000 (05:16 +0000)]
Check for conflicts between macros 1.0 exports (`#[macro_export]`, `#[macro_reexport]`)
and macros 2.0 exports (`pub use` macro re-exports and `pub macro` (once implemented)
at the crate root.
bors [Tue, 21 Mar 2017 19:50:17 +0000 (19:50 +0000)]
Auto merge of #40601 - stjepang:sort-unstable, r=alexcrichton
Implement feature sort_unstable
Tracking issue for the feature: #40585
This is essentially integration of [pdqsort](https://github.com/stjepang/pdqsort) into libcore.
There's plenty of unsafe blocks to review. The heart of pdqsort is `fn partition_in_blocks` and is probably the most challenging function to understand. It requires some patience, but let me know if you find it too difficult - comments could always be improved.
#### Changes
* Added `sort_unstable` feature.
* Tweaked insertion sort constants for stable sort. Sorting integers is now up to 5% slower, but sorting big elements is much faster (in particular, `sort_large_big_random` is 35% faster). The old constants were highly optimized for sorting integers, so overall the configuration is more balanced now. A minor regression in case of integers is forgivable as we recently had performance improvements (#39538) that completely make up for it.
* Removed some uninteresting sort benchmarks.
* Added a new sort benchmark for string sorting.
Interesting cases:
* Expensive comparison function and string sorting - it's a really close race, but timsort performs a slightly smaller number of comparisons. This is a natural difference of bottom-up merging versus top-down partitioning.
* `large_descending` - unstable sort is faster, but both sorts should have equivalent performance. Both just check whether the slice is descending and if so, they reverse it. I blame LLVM for the discrepancy.
bors [Tue, 21 Mar 2017 14:35:18 +0000 (14:35 +0000)]
Auto merge of #40686 - alexcrichton:less-logging, r=brson
travis: Don't set `RUST_LOG` globally
I have a suspicion that this caused a large regression in cycle times by forcing
the compiler to perform more checks on every `debug!` statement, so let's test
this out by removing the `RUST_LOG` env var globally.
This regression in cycle time was witnessed between [two] [builds] where the
[PR] in question didn't do much suspicious. Judging by how the stage0 times
*also* regressed though then this is my best guess.
Corey Farwell [Tue, 21 Mar 2017 03:45:00 +0000 (23:45 -0400)]
Rollup merge of #40576 - dwrensha:mir-terminator-kind-doc-typo, r=nikomatsakis
fix innacuracy in mir TerminatorKind::SwitchInt docs
Each index of `values` corresponds to an index of `targets`, and `targets` additionally has a "default case" element at its end, so `targets.len() == values.len() + 1`, not the other way around. For example, [here](https://github.com/rust-lang/rust/blob/0aeb9c12979e6da753701a798d04105b6b1a8c28/src/librustc/mir/mod.rs#L549-L550) is a concrete instance of `SwitchInt` being constructed with `targets.len() == 2` and `values.len() == 1`.
Corey Farwell [Tue, 21 Mar 2017 03:44:57 +0000 (23:44 -0400)]
Rollup merge of #40332 - steveklabnik:extract-book, r=alexcrichton
Extract book into a submodule
Part of https://github.com/rust-lang/rust/issues/39588
We probably don't want to land this till after the beta branches on friday, but would still ❤️ a review from @alexcrichton , since I am a rustbuild noob.
This pr:
1. removes the book
2. adds it back in as a submodule
3. the submodule includes both the old book and the new book
4. it also includes an index page explaining the difference in editions
5. it also includes redirect pages for the old book URLs.
6. so we build all that stuff too.
Alex Crichton [Mon, 20 Mar 2017 21:29:14 +0000 (14:29 -0700)]
travis: Don't set `RUST_LOG` globally
I have a suspicion that this caused a large regression in cycle times by forcing
the compiler to perform more checks on every `debug!` statement, so let's test
this out by removing the `RUST_LOG` env var globally.
This regression in cycle time was witnessed between [two] [builds] where the
[PR] in question didn't do much suspicious. Judging by how the stage0 times
*also* regressed though then this is my best guess.
bors [Mon, 20 Mar 2017 05:36:36 +0000 (05:36 +0000)]
Auto merge of #40281 - jimmycuadra:try-from-from-str, r=aturon
Rename TryFrom's associated type and implement str::parse using TryFrom.
Per discussion on the tracking issue, naming `TryFrom`'s associated type `Error` is generally more consistent with similar traits in the Rust ecosystem, and what people seem to assume it should be called. It also helps disambiguate from `Result::Err`, the most common "Err".
See https://github.com/rust-lang/rust/issues/33417#issuecomment-269108968.
`TryFrom<&str>` and `FromStr` are equivalent, so have the latter provide the former to ensure that. Using `TryFrom` in the implementation of `str::parse` means types that implement either trait can use it. When we're ready to stabilize `TryFrom`, we should update `FromStr` to
suggest implementing `TryFrom<&str>` instead for new code.
See https://github.com/rust-lang/rust/issues/33417#issuecomment-277175994
and https://github.com/rust-lang/rust/issues/33417#issuecomment-277253827.
Corey Farwell [Mon, 20 Mar 2017 00:51:10 +0000 (20:51 -0400)]
Rollup merge of #40554 - nrc:rls-data, r=alexcrichton
Use rls-data crate
This basically pulls out a bunch of data structures used by save-analysis for serialization into an external crate, and pulls that crate in using Rustbuild. The RLS can then share these data structures with the compiler which in some cases will allow more efficient communication between the compiler and the RLS (i.e., without serialisation).
Along the way, I have to pull in rls-span, which is the RLS's way of defining spans (more type-safe than the compiler's built-in way). This is basically just to convert from compiler spans to RLS spans.
I also pull in the crates.io version of rustc-serialize, which is a bit annoying, but seems to be the only way to have serialisable data in an external crate. To make this work, all of the save-analysis crate has to use this version too (cc #40527).
Finally I pull in a line from #40347 to make the unstable crate checking stuff working.
There are a lot of changes to save-analysis but they are all mechanical and trivial - changing from using `From` to `Into` (because of orphan rules) being the main thing.
Corey Farwell [Mon, 20 Mar 2017 00:51:09 +0000 (20:51 -0400)]
Rollup merge of #40532 - jseyfried:improve_tokenstream_quoter, r=nrc
macros: improve the `TokenStream` quoter
This PR
- renames the `TokenStream` quoter from `qquote!` to `quote!`,
- uses `$` instead of `unquote` (e.g. `let toks: TokenStream = ...; quote!([$toks])`),
- allows unquoting `Token`s as well as `TokenTree`s and `TokenStream`s (fixes #39746), and
- to preserve syntactic space, requires that `$` be followed by
- a single identifier to unquote, or
- another `$` to produce a literal `$`.
Corey Farwell [Mon, 20 Mar 2017 00:51:08 +0000 (20:51 -0400)]
Rollup merge of #40521 - TimNN:panic-free-shift, r=alexcrichton
Implemente overflowing_sh* with new unchecked_sh* intrinsics
Also update some 128 bit builtins to not rely on the constant evaluator to avoid checked operations.
Fixes #40508.
cc @nagisa, @alexcrichton
Note: I still have a build running to see if the 128 bit changes worked (unoptimized builds take *forever* to compile), however at least the overflowing builtins no longer reference `core::panicking::panic`.
Corey Farwell [Mon, 20 Mar 2017 00:51:07 +0000 (20:51 -0400)]
Rollup merge of #40398 - eddyb:struct-hint, r=nikomatsakis
Propagate expected type hints through struct literals.
Partial fix for #31260 to maximize backwards-compatibility, i.e. the hint is provided but not coerced to.
The added test works because `{...; x}` with a hint of `T` coerces `x` to `T`, and the reasoning why that is slightly different has to do with DSTs: `&Struct { tail: [x] }: &Struct<[T]>` has a hint of `[T]` for `[x]`, but the inferred type should be `[T; 1]` to succeed later, so `[x]` shouldn't be *forced* to be `[T]`.
*However*, implementing that complete behavior in a backwards-compatible way may be non-trivial, and has not yet been fully investigated, while this PR fixes #40355 and can be backported.
Corey Farwell [Mon, 20 Mar 2017 00:51:06 +0000 (20:51 -0400)]
Rollup merge of #40281 - jimmycuadra:try-from-from-str, r=aturon
Rename TryFrom's associated type and implement str::parse using TryFrom.
Per discussion on the tracking issue, naming `TryFrom`'s associated type `Error` is generally more consistent with similar traits in the Rust ecosystem, and what people seem to assume it should be called. It also helps disambiguate from `Result::Err`, the most common "Err".
See https://github.com/rust-lang/rust/issues/33417#issuecomment-269108968.
`TryFrom<&str>` and `FromStr` are equivalent, so have the latter provide the former to ensure that. Using `TryFrom` in the implementation of `str::parse` means types that implement either trait can use it. When we're ready to stabilize `TryFrom`, we should update `FromStr` to
suggest implementing `TryFrom<&str>` instead for new code.
See https://github.com/rust-lang/rust/issues/33417#issuecomment-277175994
and https://github.com/rust-lang/rust/issues/33417#issuecomment-277253827.
Corey Farwell [Mon, 20 Mar 2017 00:51:06 +0000 (20:51 -0400)]
Rollup merge of #40241 - Sawyer47:fix-39997, r=alexcrichton
Change how the `0` flag works in format!
Now it always implies right-alignment, so that padding zeroes are placed after the sign (if any) and before the digits. In other words, it always takes precedence over explicitly specified `[[fill]align]`. This also affects the '#' flag: zeroes are placed after the prefix (0b, 0o, 0x) and before the digits.
Here's a short summary of how similar format strings work in Python and Rust:
bors [Sun, 19 Mar 2017 21:02:53 +0000 (21:02 +0000)]
Auto merge of #39799 - dpc:create_dir_all, r=alexcrichton
Fix race condition in fs::create_dir_all
The code would crash if the directory was created after create_dir_all
checked whether the directory already existed. This was contrary to
the documentation which claimed to create the directory if it doesn't
exist, implying (but not stating) that there would not be a failure
due to the directory existing.
projects / rust.git / log