bors [Wed, 22 May 2019 08:22:17 +0000 (08:22 +0000)]
Auto merge of #59445 - alexreg:ban-multi-trait-objects-via-aliases, r=oli-obk
Ban multi-trait objects via trait aliases
Obviously, multi-trait objects are not normally supported, so they should not be supported via trait aliases.
This has been factored out from the previous PR https://github.com/rust-lang/rust/pull/55994 (see point 1).
r? @Centril
CC @nikomatsakis
------------------
### RELNOTES:
We now allow `dyn Send + fmt::Debug` with equivalent semantics to `dyn fmt::Debug + Send`.
That is, the order of the mentioned traits does not matter wrt. principal/not-principal traits.
This is a small change that might deserve a mention in the blog post because it is a language change but most likely not.
bors [Wed, 22 May 2019 04:42:20 +0000 (04:42 +0000)]
Auto merge of #60840 - tmandry:preserve-scope-in-generator-mir, r=cramertj
Preserve local scopes in generator MIR
Part of #52924, depended upon by the generator layout optimization #60187.
This PR adds `StorageDead` statements in more places in generators, so we can see when non-`Drop` locals have gone out of scope and recover their storage.
The reason this is only done for generators is compiler performance. See https://github.com/rust-lang/rust/pull/60187#issuecomment-485637811 for what happens when we do this for all functions.
For `Drop` locals, we modify the `MaybeStorageLive` analysis to use `drop` to indicate that storage is no longer live for the local. Once `drop` returns or unwinds to our function, we implicitly assume that the local is `StorageDead`.
Instead of using `drop`, it is possible to emit more `StorageDead` statements in the MIR for `Drop` locals so we can handle all locals the same. I am fine with doing it that way, but this was the simplest approach for my purposes. It is also likely to be more performant.
r? @Zoxc (feel free to reassign)
cc @cramertj @eddyb @RalfJung @rust-lang/wg-async-await
bors [Wed, 22 May 2019 01:51:31 +0000 (01:51 +0000)]
Auto merge of #61027 - Centril:rollup-oewauf1, r=Centril
Rollup of 10 pull requests
Successful merges:
- #59742 (Move `edition` outside the hygiene lock and avoid accessing it)
- #60581 (convert custom try macro to `?`)
- #60963 (Update boxed::Box docs on memory layout)
- #60973 (Avoid symbol interning in `file_metadata`.)
- #60982 (Do not fail on child without DefId)
- #60991 (LocalDecl push returns Local len)
- #60995 (Add stream_to_parser_with_base_dir)
- #60998 (static_assert: make use of anonymous constants)
- #61003 (Remove impls for `InternedString`/string equality.)
- #61006 (adjust deprecation date of mem::uninitialized)
Rollup merge of #61006 - RalfJung:maybe-uninit, r=Centril
adjust deprecation date of mem::uninitialized
In https://github.com/rust-lang/rust/pull/60445 we [decided](https://github.com/rust-lang/rust/pull/60445#issuecomment-488626308) that we'd deprecate for 1.38 instead of 1.40, but I forgot to adjust for that.
Rollup merge of #60995 - topecongiro:parser-from-stream-and-base-dir, r=michaelwoerister
Add stream_to_parser_with_base_dir
This PR adds `stream_to_parser_with_base_dir`, which creates a parser from a token stream and a base directory.
Context: I would like to parse `cfg_if!` macro and get a list of modules defined inside it from rustfmt so that rustfmt can format those modules (cc https://github.com/rust-lang/rustfmt/issues/3253). To do so, I need to create a parser from `TokenStream` and set the directory of `Parser` to the same directory as the parent directory of a file which contains `cfg_if!` invocation. AFAIK there is no way to achieve this, and hence this PR.
Alternatively, I could change the visibility of `Parser.directory` from `crate` to `pub` so that the value can be modified after initializing a parser. I don't have a preference over either approach (or others, as long as it works).
Rollup merge of #60973 - nnethercote:fix-file_metadata-more, r=michaelwoerister
Avoid symbol interning in `file_metadata`.
This commit changes `created_files` so it uses strings directly as keys,
rather than symbols derived from the strings. This avoids the cost of
having to do the hash table lookups to produce the symbols from the
strings.
The commit also uses `entry` to avoid doing a repeated hash table lookup
(`get` + `insert`).
Note that PR #60467 improved this code somewhat; this is a further
improvement.
Rollup merge of #60963 - blkerby:boxed_docs, r=alexcrichton
Update boxed::Box docs on memory layout
The existing docs for the `Box` type state that "the way `Box` allocates and releases memory is unspecified", and that therefore the only valid pointer to pass to `Box::from_raw` is one obtained from `Box::into_raw`. This is inconsistent with the module-level docs which specify,
> It is valid to convert both ways between a Box and a raw pointer allocated with the Global allocator, given that the Layout used with the allocator is correct for the type. More precisely, a value: *mut T that has been allocated with the Global allocator with Layout::for_value(&*value) may be converted into a box using Box::<T>::from_raw(value). Conversely, the memory backing a value: *mut T obtained from Box::<T>::into_raw may be deallocated using the Global allocator with Layout::for_value(&*value).
This pull request updates the docs for `Box` to make them consistent with the module-level docs and adds some examples of how to use the global allocator in conjunction with `Box::from_raw` and `Box::into_raw`.
bors [Tue, 21 May 2019 21:37:41 +0000 (21:37 +0000)]
Auto merge of #61007 - michaelwoerister:limited-debuginfo, r=alexcrichton
debuginfo: Revert to old/more verbose behavior for -Cdebuginfo=1
https://github.com/rust-lang/rust/commit/cff075009 made LLVM emit less debuginfo when compiling with "line-tables-only". The change was essentially correct but the reduced amount of debuginfo broke
a number of tools.
This commit reverts the change so we get back the old behavior, until we figure out how to do this properly and give external tools to adapt to the new format.
See https://github.com/rust-lang/rust/issues/60020 for more info.
debuginfo: Revert to old/more verbose behavior for -Cdebuginfo=1.
https://github.com/rust-lang/rust/commit/cff075009 made LLVM emit
less debuginfo when compiling with "line-tables-only". The change
was essentially correct but the reduced amount of debuginfo broke
a number of tools.
This commit reverts the change so we get back the old behavior,
until we figure out how to do this properly and give external
tools to adapt to the new format.
See https://github.com/rust-lang/rust/issues/60020 for more info.
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.
This commit changes `created_files` so it uses strings directly as keys,
rather than symbols derived from the strings. This avoids the cost of
having to do the hash table lookups to produce the symbols from the
strings.
The commit also uses `entry` to avoid doing a repeated hash table lookup
(`get` + `insert`).
Note that PR #60467 improved this code somewhat; this is a further
improvement.
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.
projects / rust.git / log