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.
bors [Mon, 12 Nov 2018 04:12:26 +0000 (04:12 +0000)]
Auto merge of #55701 - tromey:ice-fix, r=matthewjasper
Fix emission of niche-filling discriminant values
Bug #55606 points out a regression introduced by #54004; namely that
an assertion can erroneously fire when a niche-filling discriminant
value is emitted.
This fixes the bug by removing the assertion, and furthermore by
arranging for the discriminant value to be masked according to the
size of the niche. This makes handling the discriminant a bit simpler
for debuggers.
bors [Mon, 12 Nov 2018 01:20:33 +0000 (01:20 +0000)]
Auto merge of #55525 - nnethercote:MatcherPos-stack-SmallVec, r=nnethercote
Make `MatcherPos::stack` a `SmallVec`.
This avoids some allocations.
This seems like a trivial change, but the compiler rejects it:
```
Compiling syntax v0.0.0 (/home/njn/moz/rust1/src/libsyntax)
error[E0597]: `initial` does not live long enough=========> ] 89/110: syntax
--> libsyntax/ext/tt/macro_parser.rs:647:57
|
647 | let mut cur_items = smallvec![MatcherPosHandle::Ref(&mut initial)];
| ^^^^^^^^^^^^ borrowed value does not live long enough
...
762 | }
| -
| |
| `initial` dropped here while still borrowed
| borrow later used here, when `initial` is dropped
error: aborting due to previous error
```
This is either a compiler bug, or there's some subtle thing I don't understand. The lifetimes sure seem straightforward: `initial` is declared, and then `cur_items` is declared immediately afterward, and it uses a reference to `initial`. The error message makes it sound like the compiler is dropping the variables in the wrong order.
bors [Sun, 11 Nov 2018 19:51:56 +0000 (19:51 +0000)]
Auto merge of #55660 - alexcrichton:cleanup-alloc-system, r=dtolnay,SimonSapin
Remove the `alloc_system` crate
In what's hopefully one of the final nails in the coffin of the "old allocator story of yore" this PR deletes the `alloc_system` crate and all traces of it from the compiler. The compiler no longer needs to inject allocator crates anywhere and the `alloc_system` crate has no real reason to exist outside the standard library.
The unstable `alloc_system` crate is folded directly into the standard library where its stable interface, the `System` type, remains the same. All unstable traces of `alloc_system` are removed, however.
Alex Crichton [Sat, 3 Nov 2018 18:15:48 +0000 (11:15 -0700)]
std: Delete the `alloc_system` crate
This commit deletes the `alloc_system` crate from the standard
distribution. This unstable crate is no longer needed in the modern
stable global allocator world, but rather its functionality is folded
directly into the standard library. The standard library was already the
only stable location to access this crate, and as a result this should
not affect any stable code.
Alex Crichton [Sat, 3 Nov 2018 17:51:31 +0000 (10:51 -0700)]
rustc: Clean up allocator injection logic
This commit cleans up allocator injection logic found in the compiler
around selecting the global allocator. It turns out that now that
jemalloc is gone the compiler never actually injects anything! This
means that basically everything around loading crates here and there can
be easily pruned.
This also removes the `exe_allocation_crate` option from custom target
specs as it's no longer used by the compiler anywhere.
bors [Sun, 11 Nov 2018 17:05:36 +0000 (17:05 +0000)]
Auto merge of #55657 - davidtwco:issue-55651, r=pnkfelix
NLL Diagnostic Review 3: Unions not reinitialized after assignment into field
Fixes #55651, #55652.
This PR makes two changes:
First, it updates the dataflow builder to add an init for the place
containing a union if there is an assignment into the field of
that union.
Second, it stops a "use of uninitialized" error occuring when there is an
assignment into the field of an uninitialized union that was previously
initialized. Making this assignment would re-initialize the union, as
tested in `src/test/ui/borrowck/borrowck-union-move-assign.nll.stderr`.
The check for previous initialization ensures that we do not start
supporting partial initialization yet (cc #21232, #54499, #54986).
This PR also fixes #55652 which was marked as requiring investigation
as the changes in this PR add an error that was previously missing
(and mentioned in the review comments) and confirms that the error
that was present is correct and a result of earlier partial
initialization changes in NLL.
r? @pnkfelix (due to earlier work with partial initialization)
cc @nikomatsakis
kennytm [Sun, 11 Nov 2018 04:34:23 +0000 (12:34 +0800)]
Rollup merge of #55856 - QuietMisdreavus:static-discharge, r=GuillaumeGomez
rustdoc: refactor: move all static-file include!s into a single module
This is a smaller refactor that creates a new module `rustdoc::html::static_files`, which contains a bunch of `static` variables with all the files in `html/static` that we use. The idea behind moving them all here was to remove the duplicate `include_bytes!()` that are used by the theme-checker code. It also continues to centralize more operations in rustdoc.
kennytm [Sun, 11 Nov 2018 04:33:50 +0000 (12:33 +0800)]
Rollup merge of #55845 - nikic:emscripten-clamp-mode, r=alexcrichton
Set BINARYEN_TRAP_MODE=clamp
This fixes the wasm32-unknown-emscripten test failure mentioned in https://github.com/rust-lang/rust/pull/55626#issuecomment-437084774, by making binaryen operate in clamp rather than trap mode.
The issue is that the current `-Zsaturating-float-casts` implementation uses `fpto[us]i` unconditionally (and selects afterwards), which does not work with trapping implementations of fpto[su]i, which emscripten uses by default.
I've left a FIXME to drop this flag once we have a better solution for saturating casts on the LLVM side.
;
kennytm [Sun, 11 Nov 2018 04:32:01 +0000 (12:32 +0800)]
Rollup merge of #55630 - petrochenkov:noprelude, r=Centril
resolve: Filter away macro prelude in modules with `#[no_implicit_prelude]` on 2018 edition
This is a tiny thing.
For historical reasons macro prelude (macros from `#[macro_use] extern crate ...`, including `extern crate std`) is still available in modules with `#[no_implicit_prelude]`.
This PR provides proper isolation and removes those names from scope.
`#[no_implicit_prelude]` modules still have built-in types (`u8`), built-in attributes (`#[inline]`) and built-in macros (`env!("PATH")`) in scope. We can introduce some `#[no_implicit_prelude_at_all]` to remove those as well, but that's a separate issue.
The change is done only on 2018 edition for backward compatibility.
I'm pretty sure this can be done on 2015 as well because `#[no_implicit_prelude]` is rarely used, but I don't want to go through the crater/deprecation process right now, maybe later.
cc https://github.com/rust-lang/rust/issues/53977
r? @ghost
bors [Sun, 11 Nov 2018 03:44:16 +0000 (03:44 +0000)]
Auto merge of #54993 - TimNN:pda-tdl, r=eddyb
Support for the program data address space option of LLVM's Target Datalayout
This was introduced recently (specifically, for AVR, cc @dylanmckay).
(I came up with this when attempting to run [avr-rust](https://github.com/avr-rust/rust) rebased on the latest [rust-lang](https://github.com/rust-lang/rust) commits. If this requires a different design, some additional discussions, or is not something to pursue right now, I'd be happy to close this PR).
Note that this somewhat overlaps with @DiamondLovesYou's #51576, I think, although the implementation here is significantly simpler: Since the address space applies to _all_ program data, we can just check the pointee's type whenever we create an LLVM pointer type. If it is a function we use the program data address space; if not we use the default address space.
Pietro Albini [Sat, 10 Nov 2018 23:21:19 +0000 (00:21 +0100)]
Rollup merge of #55802 - wesleywiser:inlined_calls_2_electric_boogaloo, r=nagisa
Don't inline virtual calls (take 2)
When I fixed the previous mis-optimizations, I didn't realize there were
actually two different places where we mutate `callsites` and both of
them should have the same behavior.
As a result, if a function was inlined and that function contained
virtual function calls, they were incorrectly being inlined. I also
added a test case which covers this.
Pietro Albini [Sat, 10 Nov 2018 23:21:17 +0000 (00:21 +0100)]
Rollup merge of #55801 - pnkfelix:update-box-insensitivity-test-for-nll, r=davidtwco
NLL: Update box insensitivity test
This is just keeping one of our tests honest with respect to NLL, in two ways:
1. Adds uses of borrows that would otherwise be too short to observe the error that we would have expected to see...
2. ... I say "would have expected" because all of the errors in this file are part of the reversion of rust-lang/rfcs#130 that is attached to NLL (you can see more discussion of this here https://github.com/rust-lang/rust/issues/43234#issuecomment-411017768 )
Pietro Albini [Sat, 10 Nov 2018 23:21:11 +0000 (00:21 +0100)]
Rollup merge of #55687 - alexreg:fix-24010, r=scalexm
Take supertraits into account when calculating associated types
Fixes #24010 and #23856. Applies to trait aliases too.
As a by-product, this PR also makes repeated bindings of the same associated item in the same definition a hard error. This was previously a warning with a note about it becoming a hard error in the future. See #50589 for more info.
I talked about this with @nikomatsakis recently, but only very superficially, so this shouldn't stop anyone from assigning it to themself to review and r+.
N.B. The "WIP" commits represent imperfect attempts to solve the problem just for trait objects, but I've left them in for reference for the sake of whomever is reviewing this.
bors [Sat, 10 Nov 2018 23:16:25 +0000 (23:16 +0000)]
Auto merge of #54864 - ljedrz:cleanup_codegen_llvm_back, r=Mark-Simulacrum
Cleanup codegen_llvm/back
- improve allocations
- use `Cow<'static, str>` where applicable
- use `to_owned` instead of `to_string` with string literals
- remove a redundant `continue`
- possible minor speedup in logic
- use `mem::replace` instead of `swap` where more concise
- remove `'static` from consts
- improve common patterns
- remove explicit `return`s
- whitespace & formatting fixes
bors [Sat, 10 Nov 2018 19:58:14 +0000 (19:58 +0000)]
Auto merge of #55650 - nikic:funnel-shift, r=nagisa
Implement rotate using funnel shift on LLVM >= 7
Implement the rotate_left and rotate_right operations using
llvm.fshl and llvm.fshr if they are available (LLVM >= 7).
Originally I wanted to expose the funnel_shift_left and
funnel_shift_right intrinsics and implement rotate_left and
rotate_right on top of them. However, emulation of funnel
shifts requires emitting a conditional to check for zero shift
amount, which is not necessary for rotates. I was uncomfortable
doing that here, as I don't want to rely on LLVM to optimize
away that conditional (and for variable rotates, I'm not sure it
can). We should revisit that question when we raise our minimum
version requirement to LLVM 7 and don't need emulation code
anymore.
Wesley Wiser [Wed, 7 Nov 2018 03:31:09 +0000 (22:31 -0500)]
Don't inline virtual calls (take 2)
When I fixed the previous mis-optimizations, I didn't realize there were
actually two different places where we mutate `callsites` and both of
them should have the same behavior.
As a result, if a function was inlined and that function contained
virtual function calls, they were incorrectly being inlined. I also
added a test case which covers this.
bors [Sat, 10 Nov 2018 01:16:02 +0000 (01:16 +0000)]
Auto merge of #55626 - nikic:update-emscripten, r=alexcrichton
Update emscripten
This updates emscripten to 1.38.15, which is based on LLVM 6.0.1 and would allow us to drop code for handling LLVM 4.
The main issue I ran into is that exporting statics through `EXPORTED_FUNCTIONS` no longer works. As far as I understand exporting non-functions doesn't really make sense under emscripten anyway, so I've modified the symbol export code to not even try.
bors [Fri, 9 Nov 2018 06:56:25 +0000 (06:56 +0000)]
Auto merge of #55803 - Mark-Simulacrum:rollup, r=Mark-Simulacrum
Rollup of 17 pull requests
Successful merges:
- #55576 (Clarify error message for -C opt-level)
- #55633 (Support memcpy/memmove with differing src/dst alignment)
- #55638 (Fix ICE in msg_span_from_free_region on ReEmpty)
- #55659 (rustc: Delete grouping logic from the musl target)
- #55719 (Sidestep link error from rustfix'ed code by using a *defined* static.)
- #55736 (Elide anon lifetimes in conflicting impl note)
- #55739 (Consume optimization fuel from the MIR inliner)
- #55742 (Avoid panic when matching function call)
- #55753 (borrow_set: remove a helper function and a clone it uses)
- #55755 (Improve creation of 3 IndexVecs)
- #55758 ([regression - rust2018]: unused_mut lint false positives on nightly)
- #55760 (Remove intermediate font specs)
- #55761 (mir: remove a hacky recursive helper function)
- #55774 (wasm32-unknown-emscripten expects the rust_eh_personality symbol)
- #55777 (Use `Lit` rather than `P<Lit>` in `ast::ExprKind`.)
- #55783 (Deprecate mpsc channel selection)
- #55788 (rustc: Request ansi colors if stderr isn't a tty)
Mark Rousskov [Fri, 9 Nov 2018 01:15:24 +0000 (18:15 -0700)]
Rollup merge of #55788 - alexcrichton:wincolors, r=petrochenkov
rustc: Request ansi colors if stderr isn't a tty
Currently Cargo will always capture the output of rustc meaning that
rustc is never hooked up to a tty. To retain colors Cargo uses the
`fwdansi` crate to ensure that ansi color codes are translated to
windows terminal methods (and ansi codes otherwise just go their natural
route on Unix).
Cargo passes `--color always` to rustc to ensure that using a pipe
doesn't trick it into not emitting colors at all. It turns out, however,
that `--color always` ends up still accidentally using the native shell
api on native windows shells.
The fix here is to instead pass `AlwaysAnsi` to `termcolor` instead of
`Always`, ensuring that when `--color always` is passed to rustc and its
output isn't a terminal, we're always generating ansi colors regardless
of the platform.
Mark Rousskov [Fri, 9 Nov 2018 01:15:17 +0000 (18:15 -0700)]
Rollup merge of #55774 - CryZe:patch-5, r=alexcrichton
wasm32-unknown-emscripten expects the rust_eh_personality symbol
The `wasm32-unknown-emscripten` expects the `rust_eh_personality` symbol to be there, but a cfg checking for `target_arch = "wasm32"` which was meant to remove the symbol from the `wasm32-unknown-unknown` target, didn't check for whether `emscripten` is targeted or not, so the symbol accidentally got filtered out there as well.
Mark Rousskov [Fri, 9 Nov 2018 01:15:12 +0000 (18:15 -0700)]
Rollup merge of #55760 - jonhoo:no-intermediate-fonts, r=GuillaumeGomez
Remove intermediate font specs
This is a (much) more constrained version of #54772 that also aims at improving the situation in #34681. It removes any font specifications that are not the "official" rustdoc font, and instead relies on the browser to provide the fallback font if the official on is not available. On Linux systems, this is particularly important, as fonts like Helvetica, Arial, and Times often look pretty bad since they're pulled from extracted MS fonts. A specification like `serif` or `sans-serif` lets the browser instead choose a good font.
Mark Rousskov [Fri, 9 Nov 2018 01:15:10 +0000 (18:15 -0700)]
Rollup merge of #55758 - davidtwco:issue-55344, r=pnkfelix
[regression - rust2018]: unused_mut lint false positives on nightly
Fixes #55344.
This commit filters out locals that have never been initialized for
consideration in the `unused_mut` lint.
This is intended to detect when the statement that would have
initialized the local was removed as unreachable code. In these cases,
we would not want to lint. This is the same behaviour as the AST borrow
checker.
This is achieved by taking advantage of an existing pass over the MIR
for the `unused_mut` lint and creating a set of those locals that were
never initialized.
Mark Rousskov [Fri, 9 Nov 2018 01:15:03 +0000 (18:15 -0700)]
Rollup merge of #55742 - F001:fix-55718, r=petrochenkov
Avoid panic when matching function call
Fix #55718
This bug is introduced by #53751. The original code checked `Def::AssociatedConst(..) | Def::Method(..)` before `pat_ty.no_bound_vars().expect("expected fn type")`. But somehow I exchanged the sequence carelessly. Sorry about that.
Mark Rousskov [Fri, 9 Nov 2018 01:14:56 +0000 (18:14 -0700)]
Rollup merge of #55719 - pnkfelix:issue-54388-sidestep-link-error-from-rustfixed-code, r=alexcrichton
Sidestep link error from rustfix'ed code by using a *defined* static.
As a drive-by, added `-g` to the compile-flags so that the test more
reliably fails to compile when the extern static in question is *not*
provided. (I.e. this is making the test more robust in the face of
potential future revisions.)
Mark Rousskov [Fri, 9 Nov 2018 01:14:53 +0000 (18:14 -0700)]
Rollup merge of #55659 - alexcrichton:musl-no-group, r=michaelwoerister
rustc: Delete grouping logic from the musl target
This commit deletes the injection of `-(` and `-)` options to the linker
for the musl targets. This actually causes problems today on nightly if
you execute:
you get a linker error about "cannot nest groups". This comes about
because rustc injects its own `--start-group` and `--end-group`
variables which clash with the outer `-(` and `-)` variables. It's not
entirely clear to me why this doesn't affect the musl target by default
(in `-C panic=unwind` mode).
The compiler's own injection of `--start-group` and `--end-group` should
solve the issues mentioned in the comment for injecting `-(` and `-)` as
well.
we now, instead of ICE'ing, get a diagnostic like:
```
error[E0700]: hidden type for `impl Trait` captures lifetime that does not appear in bounds
--> issue-55608.rs:3:16
|
3 | fn server() -> impl FilterBase2 {
| ^^^^^^^^^^^^^^^^
|
= note: hidden type `Map2<[closure@issue-55608.rs:4:36: 4:41]>` captures an empty lifetime
```
Mark Rousskov [Fri, 9 Nov 2018 01:14:49 +0000 (18:14 -0700)]
Rollup merge of #55633 - nikic:memcpy-align, r=nagisa
Support memcpy/memmove with differing src/dst alignment
If LLVM 7 is used, generate memcpy/memmove with differing src/dst alignment. I've added new FFI functions to construct these through the builder API, which is more convenient than dealing with differing intrinsic signatures depending on the LLVM version.
(The commit prior to this actual passes our test suite, "thanks"
to #55695. But since I am aware of that bug, I took advantage of it
in choosing how to order my commit series...)