Matthew Jasper [Wed, 3 Apr 2019 19:54:23 +0000 (20:54 +0100)]
Emit fake borrows for all tests
I was incorrectly under the impression that this would only lead to
duplicates. See `mir-opt/match-arm-scope.rs` (upcomming commit) for a
case where we didn't emit a fake borrow of `items.1`.
bors [Tue, 21 May 2019 00:50:12 +0000 (00:50 +0000)]
Auto merge of #60985 - cr1901:msp430-fix, r=alexcrichton
Bump LLVM submodule to fix MSP430 AsmPrinter and assembler syntax mismatch.
Moving on to steps 9 and 10 of the llvm bugfix [guide](https://rust-lang.github.io/rustc-guide/codegen/updating-llvm.html#bugfix-updates), now that Rust's copy of LLVM was [updated](https://github.com/rust-lang/llvm-project/pull/13).
This PR closes issue #59077. Nightlies following this PR should have working msp430 codegen again :D.
Thanks for the prompt response even though it took me a while to get this "simple" PR done!
Rollup merge of #60983 - petrhosek:libunwind-no-exceptions, r=alexcrichton
Set -funwind-tables and -fno-exceptions unconditionally for LLVM's libunwind
These are required otherwise libunwind will end up with undefined
references to __gxx_personality_v0 which is provided by C++ ABI
library and that's undesirable.
Rollup merge of #60972 - RalfJung:volatile, r=alexcrichton
remove confusing remarks about mixed volatile and non-volatile accesses
These comments were originally added by @ecstatic-morse in https://github.com/rust-lang/rust/commit/911d35f0bfd207112806eaec2763201dad06d1c7 and then later edited by me. The intention, I think, was to make sure people do both their reads and writes with these methods if the affected memory really is used for communication with external devices.
However, [people read this as saying that mixed volatile/non-volatile accesses are UB](https://github.com/rust-lang/rust/issues/58599#issuecomment-493791130), which -- to my knowledge -- they are not. So better remove this.
I went into some detail on the time complexity of `push` because it is relevant for using BinaryHeap efficiently -- specifically that you should avoid pushing many elements in ascending order when possible.
Rollup merge of #60915 - michaelwoerister:hashstablestuff, r=estebank
stable hashing: Remove unused field and add documentation.
This PR removes the `bytes_hashed` field from `StableHasher` which in the past has been used for collecting some statistics but has gone unused for quite a while (months at least) now.
The PR also tries to document some requirements for `HashStable` implementations that haven't been written down explicitly anywhere.
Rollup merge of #60511 - taiki-e:libstd-intra-doc, r=Dylan-DPC
Fix intra-doc link resolution failure on re-exporting libstd
Currently, re-exporting libstd items as below will [occur a lot of failures](https://gist.github.com/taiki-e/e33e0e8631ef47f65a74a3b69f456366).
```rust
pub use std::*;
```
Until the underlying issue (#56922) fixed, we can fix that so they don't propagate to downstream crates.
Related: https://github.com/rust-lang/rust/pull/56941 (That PR fixed failures that occur when re-exporting from libcore to libstd.)
Petr Hosek [Mon, 20 May 2019 19:27:15 +0000 (12:27 -0700)]
Set -funwind-tables and -fno-exceptions unconditionally for LLVM's libunwind
These are required otherwise libunwind will end up with undefined
references to __gxx_personality_v0 which is provided by C++ ABI
library and that's undesirable.
bors [Mon, 20 May 2019 15:05:04 +0000 (15:05 +0000)]
Auto merge of #60445 - RalfJung:maybe-uninit, r=Centril
stabilize core parts of MaybeUninit
and deprecate mem::uninitialized in the future (1.40.0). This is part of implementing https://github.com/rust-lang/rfcs/pull/1892.
Also expand the documentation a bit.
This type is currently primarily useful when dealing with partially initialized arrays. In libstd, it is used e.g. in `BTreeMap` (with some unstable APIs that however can all be replaced, less ergonomically, by stable ones). What we stabilize should also be enough for `SmallVec` (Cc @bluss).
Making this useful for structs requires https://github.com/rust-lang/rfcs/pull/2582 or a commitment that references to uninitialized data are not insta-UB.
Note that the `is_gensymed` call on `primitive_types` is unnecessary
because that table only contains the name of primitive types (e.g.
`i32`) and never contains gensyms.
bors [Mon, 20 May 2019 00:37:48 +0000 (00:37 +0000)]
Auto merge of #60969 - Centril:rollup-3j71mqj, r=Centril
Rollup of 6 pull requests
Successful merges:
- #60590 (Test interaction of unions with non-zero/niche-filling optimization)
- #60745 (Perform constant propagation into terminators)
- #60895 (Enable thumbv7a-pc-windows-msvc target build end to end in rust/master)
- #60908 (Fix lints handling in rustdoc)
- #60960 (Stop using gensyms in HIR lowering)
- #60962 (Fix data types indication)
`LocalInternedString::intern(x)` is preferable to
`Symbol::intern(x).as_str()`, because the former involves one call to
`with_interner` while the latter involves two.
`InternedString::intern(x)` is preferable to
`Symbol::intern(x).as_interned_str()`, because the former involves one
call to `with_interner` while the latter involves two.
The case within InternedString::decode() is particularly hot, and this
change reduces the number of `with_interner` calls by up to 13%.
Rollup merge of #60962 - VeryTastyTomato:patch-1, r=jonas-schievink
Fix data types indication
Fix the data types indication in basic examples of the Trait std::fmt::LowerExp and std::fmt::UpperExp.
Since there aren’t any type annotation on the let statement using the number 42.0, they are of type f64 according to The Book:
https://doc.rust-lang.org/book/ch03-02-data-types.html#floating-point-types
Rollup merge of #60960 - matthewjasper:remove-lowering-gensym, r=petrochenkov
Stop using gensyms in HIR lowering
These names aren't ever handled by resolve, so there's no reason to
make them gensyms.
Diagnostics wanting to behave differently for these variables should
inspect either the `MatchSource`/`LocalSource` or the `Span`. All
current diagnostics appear to do this.
Rollup merge of #60908 - GuillaumeGomez:errors, r=oli-obk
Fix lints handling in rustdoc
Part of #60664: now lints are handled just like any other lints you would setup in rustc. Still remains to handle `missing code examples` and `missing_docs` as part of the same group.
Rollup merge of #60895 - chandde:master, r=alexcrichton
Enable thumbv7a-pc-windows-msvc target build end to end in rust/master
With this PR, plus another commit https://github.com/rust-lang-nursery/compiler-builtins/commit/cf98161da7ed5217b6031796f0f60b4dd07148a4, I'm able to build the target thumbv7a-pc-windows-msvc successfully, and I'm able to use the stage2 artifacts to build arm32 projects. The commit in compiler_builtins is in release 0.1.14, the current cargo.lock in rust master still uses 0.1.12, so I bumped the compiler_builtins version in cargo.lock to 0.1.15
The command I used to build rust
```
c:\python27\python.exe x.py build --host x86_64-pc-windows-msvc --build x86_64-pc-windows-msvc --target thumbv7a-pc-windows-msvc --verbose
```
**Changes**
1. update cargolock to use compiler_builtins 0.1.15
2. handle libunwind in libtest for thumv7a the same as what we have for aarch64
3. in llvm codegen add a field in CodegenContext to carry the arch, so later in create_msvc_imps function, the arch can be used to check against "x86", instead of 32 pointer width. Apparently Thumv7a is handled differently than x86.
**Background**
I'm from Microsoft working on enabling Azure IoTEdge on ARM32 Windows IoTCore, Azure IoTEdge has a component called IoTEdged written in rust as a NT service running on Windows, so we need to enable rust on thumbv7a in order to have full IoTEdge. My colleague had made some heavy lifting and we've been using our private toolchain to build IoTEdged in our devops pipeline, because at that time we cannot build thumbv7a target end to end successfully. This change is a followup to enable the end to end build for thumbv7a-pc-windows-msvc target.
**Next step**
I'll submit more changes to have this target built nightly in rust/master, to achieve the same availability for aarch64-pc-windows-msvc, indexed here https://rust-lang.github.io/rustup-components-history/aarch64-pc-windows-msvc.html and can be manually installed. **Please do share what takes to make this happen, is there a formal process I need to follow\?**
Rollup merge of #60745 - wesleywiser:const_prop_into_terminators, r=oli-obk
Perform constant propagation into terminators
Perform constant propagation into MIR `Assert` and `SwitchInt` `Terminator`s which in some cases allows them to be removed by the branch simplification pass.
Rollup merge of #60590 - petertodd:2018-test-union-nonzero, r=nikomatsakis,Centril
Test interaction of unions with non-zero/niche-filling optimization
Notably this nails down part of the behavior that MaybeUninit assumes, e.g. that a Option<MaybeUninit<&u8>> does not take advantage of non-zero optimization, and thus is a safe construct.
It also verifies the status quo: that even unions that could theoretically take advantage of niches don't. (relevant: https://github.com/rust-lang/rust/issues/36394)
bors [Sun, 19 May 2019 16:48:12 +0000 (16:48 +0000)]
Auto merge of #60065 - QuietMisdreavus:async-move-doctests, r=ollie27
rustdoc: set the default edition when pre-parsing a doctest
Fixes https://github.com/rust-lang/rust/issues/59313 (possibly more? i think we've had issues with parsing edition-specific syntax in doctests at some point)
When handling a doctest, rustdoc needs to parse it beforehand, so that it can see whether it declares a `fn main` or `extern crate my_crate` explicitly. However, while doing this, rustdoc doesn't set the "default edition" used by the parser like the regular compilation runs do. This caused a problem when parsing a doctest with an `async move` block in it, since it was expecting the `move` keyword to start a closure, not a block.
This PR changes the `rustdoc::test::make_test` function to set the parser's default edition while looking for a main function and `extern crate` statement. However, to do this, `make_test` needs to know what edition to set. Since this is also used during the HTML rendering process (to make playground URLs), now the HTML renderer needs to know about the default edition. Upshot: rendering standalone markdown files can now accept a "default edition" for their doctests with the `--edition` flag! (I'm pretty sure i waffled around how to set that a long time ago when we first added the `--edition` flag... `>_>`)
I'm posting this before i stop for the night so that i can write this description while it's still in my head, but before this merges i want to make sure that (1) the `rustdoc-ui/failed-doctest-output` test still works (i expect it doesn't), and (2) i add a test with the sample from the linked issue.
VeryTastyTomato [Sun, 19 May 2019 13:51:46 +0000 (13:51 +0000)]
Fix data types indication
Fix the data types indication in basic examples of the Trait std::fmt::LowerExp and std::fmt::UpperExp.
Since there aren’t any type annotation on the let statement using the number 42.0, they are of type f64 according to The Book:
https://doc.rust-lang.org/book/ch03-02-data-types.html#floating-point-types
David Tolnay [Sun, 19 May 2019 03:25:15 +0000 (20:25 -0700)]
Document BinaryHeap time complexity
I went into some detail on the time complexity of `push` because it is
relevant for using BinaryHeap efficiently -- specifically that you
should avoid pushing many elements in ascending order when possible.
bors [Sun, 19 May 2019 01:56:14 +0000 (01:56 +0000)]
Auto merge of #60949 - Centril:rollup-f918e1v, r=Centril
Rollup of 8 pull requests
Successful merges:
- #60370 (Mark core::alloc::Layout::from_size_align_unchecked const)
- #60678 (Stabilize vecdeque_rotate)
- #60924 (Explain that ? converts the error type using From)
- #60931 (Use iter() for iterating arrays by slice)
- #60934 (Declare DefIndex with the newtype_index macro)
- #60943 (fix copy-paste typo in docs for ptr::read_volatile)
- #60945 (Simplify BufRead::fill_buf doc example using NLL)
- #60947 (Fix typos in docs of GlobalAlloc)
Rollup merge of #60931 - cuviper:array-iter, r=KodrAus
Use iter() for iterating arrays by slice
These `into_iter()` calls will change from iterating references to
values if we ever get `IntoIterator` for arrays, which may break the
code using that iterator. Calling `iter()` is future proof.
Josh Stone [Sat, 18 May 2019 02:56:35 +0000 (19:56 -0700)]
Use iter() for iterating arrays by slice
These `into_iter()` calls will change from iterating references to
values if we ever get `IntoIterator` for arrays, which may break the
code using that iterator. Calling `iter()` is future proof.
bors [Fri, 17 May 2019 23:06:51 +0000 (23:06 +0000)]
Auto merge of #49799 - hdhoang:46205_deny_incoherent_fundamental_impls, r=nikomatsakis
lint: convert incoherent_fundamental_impls into hard error
*Summary for affected authors:* If your crate depends on one of the following crates, please upgrade to a newer version:
- gtk-rs: upgrade to at least 0.4
- rusqlite: upgrade to at least 0.14
- nalgebra: upgrade to at least 0.15, or the last patch version of 0.14
- spade: upgrade or refresh the Cargo.lock file to use version 1.7
- imageproc: upgrade to at least 0.16 (newer versions no longer use nalgebra)