Pietro Albini [Thu, 15 Nov 2018 10:04:46 +0000 (11:04 +0100)]
Rollup merge of #55932 - Turbo87:to_digit, r=alexcrichton
core/char: Speed up `to_digit()` for `radix <= 10`
I noticed that `char::to_digit()` seemed to do a bit of extra work for handling `[a-zA-Z]` characters. Since `to_digit(10)` seems to be the most common case (at least in the `rust` codebase) I thought it might be valuable to create a fast path for that case, and according to the benchmarks that I added in one of the commits it seems to pay off. I also created another fast path for the `radix < 10` case, which also seems to have a positive effect.
It is very well possible that I'm measuring something entirely unrelated though, so please verify these numbers and let me know if I missed something!
### Before
```
# Run 1
test char::methods::bench_to_digit_radix_10 ... bench: 16,265 ns/iter (+/- 1,774)
test char::methods::bench_to_digit_radix_16 ... bench: 13,938 ns/iter (+/- 2,479)
test char::methods::bench_to_digit_radix_2 ... bench: 13,090 ns/iter (+/- 524)
test char::methods::bench_to_digit_radix_36 ... bench: 14,236 ns/iter (+/- 1,949)
# Run 2
test char::methods::bench_to_digit_radix_10 ... bench: 16,176 ns/iter (+/- 1,589)
test char::methods::bench_to_digit_radix_16 ... bench: 13,896 ns/iter (+/- 3,140)
test char::methods::bench_to_digit_radix_2 ... bench: 13,158 ns/iter (+/- 1,112)
test char::methods::bench_to_digit_radix_36 ... bench: 14,206 ns/iter (+/- 1,312)
# Run 3
test char::methods::bench_to_digit_radix_10 ... bench: 16,221 ns/iter (+/- 2,423)
test char::methods::bench_to_digit_radix_16 ... bench: 14,361 ns/iter (+/- 3,926)
test char::methods::bench_to_digit_radix_2 ... bench: 13,097 ns/iter (+/- 671)
test char::methods::bench_to_digit_radix_36 ... bench: 14,388 ns/iter (+/- 1,068)
```
### After
```
# Run 1
test char::methods::bench_to_digit_radix_10 ... bench: 11,521 ns/iter (+/- 552)
test char::methods::bench_to_digit_radix_16 ... bench: 12,926 ns/iter (+/- 684)
test char::methods::bench_to_digit_radix_2 ... bench: 11,266 ns/iter (+/- 1,085)
test char::methods::bench_to_digit_radix_36 ... bench: 14,213 ns/iter (+/- 614)
# Run 2
test char::methods::bench_to_digit_radix_10 ... bench: 11,424 ns/iter (+/- 1,042)
test char::methods::bench_to_digit_radix_16 ... bench: 12,854 ns/iter (+/- 1,193)
test char::methods::bench_to_digit_radix_2 ... bench: 11,193 ns/iter (+/- 716)
test char::methods::bench_to_digit_radix_36 ... bench: 14,249 ns/iter (+/- 3,514)
# Run 3
test char::methods::bench_to_digit_radix_10 ... bench: 11,469 ns/iter (+/- 685)
test char::methods::bench_to_digit_radix_16 ... bench: 12,852 ns/iter (+/- 568)
test char::methods::bench_to_digit_radix_2 ... bench: 11,275 ns/iter (+/- 1,356)
test char::methods::bench_to_digit_radix_36 ... bench: 14,188 ns/iter (+/- 1,501)
```
Pietro Albini [Thu, 15 Nov 2018 10:04:45 +0000 (11:04 +0100)]
Rollup merge of #55930 - ljedrz:hir_bonuses, r=cramertj
A handful of hir tweaks
- remove an unused `hir_vec` macro pattern
- simplify `fmt::Debug` for `hir::Path` (take advantage of the `Display` implementation)
- remove an unused type alias (`CrateConfig`)
- simplify a `match` expression (join common patterns)
Pietro Albini [Thu, 15 Nov 2018 10:04:38 +0000 (11:04 +0100)]
Rollup merge of #55785 - stjepang:unsized-drop-forget, r=alexcrichton
Add mem::forget_unsized() for forgetting unsized values
~~Allows passing values of `T: ?Sized` types to `mem::drop` and `mem::forget`.~~
Adds `mem::forget_unsized()` that accepts `T: ?Sized`.
I had to revert the PR that removed the `forget` intrinsic and replaced it with `ManuallyDrop`: https://github.com/rust-lang/rust/pull/40559
We can't use `ManuallyDrop::new()` here because it needs `T: Sized` and we don't have support for unsized return values yet (will we ever?).
Pietro Albini [Thu, 15 Nov 2018 10:04:37 +0000 (11:04 +0100)]
Rollup merge of #55781 - pnkfelix:issue-54382-more-precise-spans-for-temps-and-their-drops, r=davidtwco
More precise spans for temps and their drops
This PR has two main enhancements:
1. when possible during code generation for a statement (like `expr();`), pass along the span of a statement, and then attribute the drops of temporaries from that statement to the statement's end-point (which will be the semicolon if it is a statement that is terminating by a semicolon).
2. when evaluating a block expression into a MIR temp, use the span of the block's tail expression (rather than the span of whole block including its statements and curly-braces) for the span of the temp.
Each of these individually increases the precision of our diagnostic output; together they combine to make a much clearer picture about the control flow through the spans.
Pietro Albini [Thu, 15 Nov 2018 10:04:31 +0000 (11:04 +0100)]
Rollup merge of #55530 - ljedrz:speed_up_String_from_utf16, r=SimonSapin
Speed up String::from_utf16
Collecting into a `Result` is idiomatic, but not necessarily fast due to rustc not being able to preallocate for the resulting collection. This is fine in case of an error, but IMO we should optimize for the common case, i.e. a successful conversion.
This changes the behavior of `String::from_utf16` from collecting into a `Result` to pushing to a preallocated `String` in a loop.
According to [my simple benchmark](https://gist.github.com/ljedrz/953a3fb74058806519bd4d640d6f65ae) this change makes `String::from_utf16` around **twice** as fast.
Pietro Albini [Thu, 15 Nov 2018 10:04:27 +0000 (11:04 +0100)]
Rollup merge of #55182 - jD91mZM2:rebased, r=alexcrichton
Redox: Update to new changes
These are all cherry-picked from our fork:
- Remove the `env:` scheme
- Update `execve` system call to `fexec`
- Interpret shebangs: these are no longer handled by the kernel, which like usual tries to be as minimal as possible
bors [Wed, 14 Nov 2018 22:15:35 +0000 (22:15 +0000)]
Auto merge of #55939 - alexcrichton:path-regression-again, r=sfackler
std: Synchronize access to global env during `exec`
This commit, after reverting #55359, applies a different fix for #46775
while also fixing #55775. The basic idea was to go back to pre-#55359
libstd, and then fix #46775 in a way that doesn't expose #55775.
The issue described in #46775 boils down to two problems:
* First, the global environment is reset during `exec` but, but if the
`exec` call fails then the global environment was a dangling pointer
into free'd memory as the block of memory was deallocated when
`Command` is dropped. This is fixed in this commit by installing a
`Drop` stack object which ensures that the `environ` pointer is
preserved on a failing `exec`.
* Second, the global environment was accessed in an unsynchronized
fashion during `exec`. This was fixed by ensuring that the
Rust-specific environment lock is acquired for these system-level
operations.
Thanks to Alex Gaynor for pioneering the solution here!
Alex Crichton [Tue, 13 Nov 2018 22:57:10 +0000 (14:57 -0800)]
std: Synchronize access to global env during `exec`
This commit, after reverting #55359, applies a different fix for #46775
while also fixing #55775. The basic idea was to go back to pre-#55359
libstd, and then fix #46775 in a way that doesn't expose #55775.
The issue described in #46775 boils down to two problems:
* First, the global environment is reset during `exec` but, but if the
`exec` call fails then the global environment was a dangling pointer
into free'd memory as the block of memory was deallocated when
`Command` is dropped. This is fixed in this commit by installing a
`Drop` stack object which ensures that the `environ` pointer is
preserved on a failing `exec`.
* Second, the global environment was accessed in an unsynchronized
fashion during `exec`. This was fixed by ensuring that the
Rust-specific environment lock is acquired for these system-level
operations.
Thanks to Alex Gaynor for pioneering the solution here!
Closes #55775
Co-authored-by: Alex Gaynor <alex.gaynor@gmail.com>
bors [Wed, 14 Nov 2018 19:25:54 +0000 (19:25 +0000)]
Auto merge of #55947 - michaelwoerister:xlto-fix-lld-opt, r=Mark-Simulacrum
xLTO: Don't pass --plugin-opt=thin to LLD. That's not supported anymore.
It seems that `-plugin-opt=thin` is not needed anymore when invoking LLD for ThinLTO. Unfortunately, still passing the option makes LLD crash instead of giving a deprecation warning or something.
bors [Wed, 14 Nov 2018 11:54:14 +0000 (11:54 +0000)]
Auto merge of #55934 - alexcrichton:appveyor-gce, r=Mark-Simulacrum
Switch AppVeyor builds to the GCE cloud
[Recommended by AppVeyor][1] this isn't done by default for all builds
due to the high startup overhead (3-4 minutes for a VM), but that's
paltry compared to our overall build times so should be more than
applicable!
Alex Crichton [Tue, 13 Nov 2018 21:38:04 +0000 (13:38 -0800)]
Switch AppVeyor builds to the GCE cloud
[Recommended by AppVeyor][1] this isn't done by default for all builds
due to the high startup overhead (3-4 minutes for a VM), but that's
paltry compared to our overall build times so should be more than
applicable!
bors [Tue, 13 Nov 2018 19:16:18 +0000 (19:16 +0000)]
Auto merge of #55356 - Aaron1011:fix/rustdoc-negative-auto, r=nikomatsakis
Check for negative impls when finding auto traits
Fixes #55321
When AutoTraitFinder begins examining a type, it checks for an explicit
negative impl. However, it wasn't checking for negative impls found when
calling 'select' on predicates found from nested obligations.
This commit makes AutoTraitFinder check for negative impls whenever it
makes a call to 'select'. If a negative impl is found, it immediately
bails out.
Normal users of SelectioContext don't need to worry about this, since
they stop as soon as an Unimplemented error is encountered. However, we
add predicates to our ParamEnv when we encounter this error, so we need
to handle negative impls specially (so that we don't try adding them to
our ParamEnv).
scalexm [Thu, 1 Nov 2018 14:09:02 +0000 (15:09 +0100)]
Use a dummy outlives requirement for `where Type:,` (see #53696)
A `WF(Type)` predicate was used previously, which did not play
well with implied bounds in chalk.
kennytm [Tue, 13 Nov 2018 05:03:24 +0000 (13:03 +0800)]
Rollup merge of #55896 - rust-lang:opt-fuse, r=shepmaster
Document optimizations enabled by FusedIterator
When reading this I wondered what “some significant optimizations” referred to. As far as I can tell from reading code, the specialization of `.fuse()` is the only case where `FusedIterator` has any impact at all. Is this accurate @Stebalien?
kennytm [Tue, 13 Nov 2018 05:03:22 +0000 (13:03 +0800)]
Rollup merge of #55889 - RalfJung:global-alloc, r=alexcrichton
global allocators: add a few comments
These comments answer some questions that came up when I tried to understand how the control flow works for the global allocator, `Global` and `System`.
This makes `PhantomData<T>` structurally matchable, irrespective of whether `T` is, per the discussion on this week's language team meeting (the general consensus was that this was a bug-fix).
All types containing `PhantomData<T>` and which used `#[derive(PartialEq, Eq)]` and were previously not `#[structural_match]` only because of `PhantomData<T>` will now be `#[structural_match]`.
kennytm [Tue, 13 Nov 2018 05:03:08 +0000 (13:03 +0800)]
Rollup merge of #55804 - QuietMisdreavus:eager-crate-inline, r=pnkfelix
rustdoc: don't inline `pub use some_crate` unless directly asked to
cc https://github.com/rust-lang/rust/issues/52509 (fixes it? i'm not sure about my comment summoning the docs team)
When rustdoc encounters a `pub use` statement for an item from another crate, it will eagerly inline its contents into your crate. This somewhat clashes with the new paths behavior in Rust 2018, in which crates are implicitly linked and re-exported with `pub use` instead of `pub extern crate`. In rust 2015, `pub extern crate` would only create a single line for its re-export in the docs, so i'm making it do the same with `pub use some_crate;`.
The exact new behavior is like this: *If rustdoc sees a `pub use` statement, and the item being imported is the root of another crate, it will only inline it if `#[doc(inline)]` is provided.* I made it only avoid crate roots because otherwise it would stop inlining any module, which may or may not be what people want.
bors [Tue, 13 Nov 2018 01:08:13 +0000 (01:08 +0000)]
Auto merge of #55052 - newpavlov:patch-2, r=alexcrichton
Use read_unaligned instead of read in transmute_copy
Closes: #55044
This change could result in performance regression on non-x86 platforms. (but it also can fix some of UB which lurks in existing programs) An alternative would be to update `transmute_copy` documentation with alignment requirements.
bors [Mon, 12 Nov 2018 18:54:11 +0000 (18:54 +0000)]
Auto merge of #55278 - Centril:constification-1, r=alexcrichton
Minor standard library constification
This PR makes some bits of the standard library into `const fn`s.
I've tried to be as aggressive as I possibly could in the constification.
The list is rather small due to how restrictive `const fn` is at the moment.
Simon Sapin [Mon, 12 Nov 2018 11:22:33 +0000 (12:22 +0100)]
Document optimizations enabled by FusedIterator
When reading this I wondered what “some significant optimizations” referred to. As far as I can tell, the specialization of `.fuse()` is the only case where `FusedIterator` has any impact at all. Is this accurate @Stebalien?