bors [Fri, 8 Nov 2019 15:52:14 +0000 (15:52 +0000)]
Auto merge of #66225 - Centril:rollup-it0t5tk, r=Centril
Rollup of 5 pull requests
Successful merges:
- #65785 (Transition future compat lints to {ERROR, DENY} - Take 2)
- #66007 (Remove "here" from "expected one of X here")
- #66043 (rename Memory::get methods to get_raw to indicate their unchecked nature)
- #66154 (miri: Rename to_{u,i}size to to_machine_{u,i}size)
- #66188 (`MethodSig` -> `FnSig` & Use it in `ItemKind::Fn`)
Rollup merge of #66043 - RalfJung:memory-get-raw, r=cramertj
rename Memory::get methods to get_raw to indicate their unchecked nature
Some recent Miri PRs started using these methods when they should not; this should discourage their use.
In fact we could make these methods private to the `interp` module as far as Miri is concerned -- with the exception of the `uninit` intrinsic which will hopefully go away soon. @bjorn3 @oli-obk does priroda need these methods? It would be great to be able to seal them away.
bors [Fri, 8 Nov 2019 07:55:53 +0000 (07:55 +0000)]
Auto merge of #66066 - ecstatic-morse:remove-promotion-from-qualify-consts, r=eddyb
Remove promotion candidate gathering and checking from `qualify_consts.rs`
This makes promotion candidate gathering and checking the exclusive domain of `promote_consts`, but the `QualifyAndPromoteConsts` pass is still responsible for both const-checking and creating promoted MIR fragments.
This should not be merged until the beta branches on Nov. 5.
bors [Fri, 8 Nov 2019 04:44:23 +0000 (04:44 +0000)]
Auto merge of #66208 - JohnTitor:rollup-2umgjer, r=JohnTitor
Rollup of 8 pull requests
Successful merges:
- #65554 (Enhance the documentation of BufReader for potential data loss)
- #65580 (Add `MaybeUninit` methods `uninit_array`, `slice_get_ref`, `slice_get_mut`)
- #66049 (consistent handling of missing sysroot spans)
- #66056 (rustc_metadata: Some reorganization of the module structure)
- #66123 (No more hidden elements)
- #66157 (Improve math log documentation examples)
- #66165 (Ignore these tests ,since the called commands doesn't exist in VxWorks)
- #66190 (rustc_target: inline abi::FloatTy into abi::Primitive.)
Failed merges:
- #66188 (`MethodSig` -> `FnSig` & Use it in `ItemKind::Fn`)
Yuki Okushi [Fri, 8 Nov 2019 04:42:24 +0000 (13:42 +0900)]
Rollup merge of #66190 - eddyb:primflt, r=Centril
rustc_target: inline abi::FloatTy into abi::Primitive.
This effectively undoes a small part of @oli-obk's #50967, now that the rest of the compiler doesn't use the `FloatTy` definition from `rustc_target`, post-#65884.
Yuki Okushi [Fri, 8 Nov 2019 04:42:21 +0000 (13:42 +0900)]
Rollup merge of #66157 - srinivasreddy:improv, r=alexcrichton
Improve math log documentation examples
using 2.0.log(2.0) in examples does not make it clear which is the base and number. This example makes it clear for programmers who take a glance at the example by following the calculation. It is more intuitive, and eliminates the need for executing the example in the playground.
Yuki Okushi [Fri, 8 Nov 2019 04:42:17 +0000 (13:42 +0900)]
Rollup merge of #66056 - petrochenkov:metapriv, r=eddyb
rustc_metadata: Some reorganization of the module structure
The new structure of `rustc_metadata` (or rather its parts affected by the refactoring) is
```
├── lib.rs
└── rmeta
├── decoder
│ └── cstore_impl.rs
├── decoder.rs
├── encoder.rs
├── mod.rs
└── table.rs
```
(`schema` is renamed to `rmeta`.)
The code inside `rmeta` is pretty self-contained, so we can now privatize almost everything in this module instead of using `pub(crate)` which was necessary when all these modules accessed their neighbors in the old flat structure.
`encoder` and `decoder` work with structures defined by `rmeta`.
`table` is a part of `rmeta`.
`cstore_impl` actively uses decoder methods and exposes their results through very few public methods (`provide` and `_untracked` methods).
Yuki Okushi [Fri, 8 Nov 2019 04:42:16 +0000 (13:42 +0900)]
Rollup merge of #66049 - RalfJung:missing-spans, r=alexcrichton
consistent handling of missing sysroot spans
Due to https://github.com/rust-lang/rust/issues/53081, sysroot spans (pointing to code in libcore/libstd/...) fails to print on some x86 runners. This consolidates the ignore directives for that and references the relevant issue.
I also did that for the generated derive-error-span tests -- but there the script and the tests were not entirely in sync any more since https://github.com/rust-lang/rust/pull/64151. Cc @estebank @varkor
Eventually these will hopefully become the idiomatic way to work with partially-initialized stack buffers.
All methods are unstable. Note that `uninit_array` takes a type-level `const usize` parameter, so it is blocked (at least in its current form) on const generics.
Example:
```rust
use std::mem::MaybeUninit;
let input = b"Foo";
let f = u8::to_ascii_uppercase;
let mut buffer: [MaybeUninit<u8>; 32] = MaybeUninit::uninit_array();
let vec;
let output = if let Some(buffer) = buffer.get_mut(..input.len()) {
buffer.iter_mut().zip(input).for_each(|(a, b)| { a.write(f(b)); });
unsafe { MaybeUninit::slice_get_ref(buffer) }
} else {
vec = input.iter().map(f).collect::<Vec<u8>>();
&vec
};
Yuki Okushi [Fri, 8 Nov 2019 04:42:12 +0000 (13:42 +0900)]
Rollup merge of #65554 - gliderkite:bufreader-doc-enhance, r=KodrAus
Enhance the documentation of BufReader for potential data loss
This is (IMO) and enhancement of the `std::io::BufReader` documentation, that aims to highlight how relatively easy is to end up with data loss when improperly using an instance of this class.
This is following the issue I had figuring out why my application was loosing data, because I focused my attention on the word *multiple instances* of `BufReader` in its `struct` documentation, even if I ever only had one instance.
Link to the issue: https://github.com/tokio-rs/tokio/issues/1662
bors [Fri, 8 Nov 2019 01:15:50 +0000 (01:15 +0000)]
Auto merge of #64882 - ehuss:stabilize-bare-extern, r=eddyb
Stabilize --extern flag without a path.
This stabilizes the `--extern` flag without a path, implemented in #54116.
This flag is used to add a crate that may be found in the search path to the extern prelude. The intent of stabilizing this now is to change Cargo to emit this flag for `proc_macro` when building a proc-macro crate. This will allow the ability to elide `extern crate proc_macro;` for proc-macros, one of the few places where it is still necessary.
It is intended that Cargo may also use this flag for other cases in the future as part of the [std-aware work](https://github.com/rust-lang/wg-cargo-std-aware/). There will likely be some kind of syntax where users may declare dependencies on other crates (such as `alloc`), and Cargo will use this flag so that they may be used like any other crate. At this time there are no short-term plans to use it for anything other than proc-macro.
This will not help for non-proc-macro crates that use `proc_macro`, which I believe is not too common?
An alternate approach for proc-macro is to use the `meta` crate, but from my inquiries there doesn't appear to be anyone interested in pushing that forward. The `meta` crate also doesn't help with things like `alloc` or `test`.
bors [Thu, 7 Nov 2019 22:02:41 +0000 (22:02 +0000)]
Auto merge of #66189 - Centril:rollup-3bsf45s, r=Centril
Rollup of 5 pull requests
Successful merges:
- #63793 (Have tidy ensure that we document all `unsafe` blocks in libcore)
- #64696 ([rustdoc] add sub settings)
- #65916 (syntax: move stuff around)
- #66087 (Update some build-pass ui tests to use check-pass where applicable)
- #66182 (invalid_value lint: fix help text)
Rollup merge of #66182 - RalfJung:invalid-value, r=Centril
invalid_value lint: fix help text
Now that we also warn about `MaybUninit::uninit().assume_init()`, just telling people "use `MaybeUninit`" isn't always sufficient. And anyway this seems like an important enough point to mention it here.
Rollup merge of #64696 - GuillaumeGomez:rustdoc-sub-settings, r=kinnison
[rustdoc] add sub settings
This PR is to give a finer control over what types are automatically expanded or not as well as the possibility to add sub-settings in the settings page.
Rollup merge of #66017 - LukasKalbertodt:array-into-iter-lint, r=matthewjasper
Add future incompatibility lint for `array.into_iter()`
This is for #65819. This lint warns when calling `into_iter` on an array directly. That's because today the method call resolves to `<&[T] as IntoIterator>::into_iter` but that would change when adding `IntoIterator` impls for arrays. This problem is discussed in detail in #65819.
We still haven't decided how to proceed exactly, but it seems like adding a lint is a good idea regardless?
Also: this is the first time I implement a lint, so there are probably a lot of things I can improve. I used a different strategy than @scottmcm describes [here](https://github.com/rust-lang/rust/pull/65819#issuecomment-548667847) since I already started implementing this before they commented.
### TODO
- [x] Decide if we want this lint -> apparently [we want](https://github.com/rust-lang/rust/pull/65819#issuecomment-548964818)
- [x] Open a lint-tracking-issue and add the correct issue number in the code -> https://github.com/rust-lang/rust/issues/66145
Rollup merge of #65974 - Centril:matcher-friendly-gating, r=petrochenkov
A scheme for more macro-matcher friendly pre-expansion gating
Pre-expansion gating will now avoid gating macro matchers that did not result in `Success(...)`. That is, the following is now OK despite `box 42` being a valid `expr` and that form being pre-expansion gated:
```rust
macro_rules! m {
($e:expr) => { 0 }; // This fails on the input below due to `, foo`.
(box $e:expr, foo) => { 1 }; // Successful matcher, we should get `2`.
}
Rollup merge of #65884 - Centril:non-hardcoded-abis, r=petrochenkov
syntax: ABI-oblivious grammar
This PR has the following effects:
1. `extern $lit` is now legal where `$lit:literal` and `$lit` is substituted for a string literal.
2. `extern "abi_that_does_not_exist"` is now *syntactically* legal whereas before, the set of ABI strings was hard-coded into the grammar of the language. With this PR, the set of ABIs are instead validated and translated during lowering. That seems more appropriate.
3. `ast::FloatTy` is now distinct from `rustc_target::abi::FloatTy`. The former is used substantially more and the translation between them is only necessary in a single place.
4. As a result of 2-3, libsyntax no longer depends on librustc_target, which should improve pipe-lining somewhat.
cc @rust-lang/lang -- the points 1-2 slightly change the definition of the language but in a way which seems consistent with our general principles (in particular wrt. the discussions of turning things into semantic errors). I expect this to be uncontroversial but it's worth letting y'all know. :)
Use structured suggestions for missing associated items
When encountering an `impl` that is missing associated items required by its `trait`, use structured suggestions at an appropriate place in the `impl`.
Rollup merge of #59789 - eddyb:typeck-reverts, r=nikomatsakis
Revert two unapproved changes to rustc_typeck.
There was a breakdown in process (https://github.com/rust-lang/rust/pull/59004#issuecomment-477600735, https://github.com/rust-lang/rust/pull/58894#discussion_r272795560) and two changes were made to `rustc_typeck`'s "collect" queries, for rustdoc, that were neither needed *nor* correct.
I'm reverting them here, and will fix up rustdoc *somehow*, if necessary.
cc @rust-lang/compiler How do we ensure this doesn't happen again?
Yuki Okushi [Thu, 7 Nov 2019 00:20:48 +0000 (09:20 +0900)]
Rollup merge of #66162 - Darksonn:master, r=ehuss
Fix broken link in README
The link to the rustc guide on building and running the compiler is broken. It was broken in [rustc-guide#491](https://github.com/rust-lang/rustc-guide/pull/491).
Yuki Okushi [Thu, 7 Nov 2019 00:20:46 +0000 (09:20 +0900)]
Rollup merge of #66147 - RalfJung:no-scalar-ptr, r=oli-obk
Miri: Refactor to_scalar_ptr out of existence
`to_scalar_ptr` is somewhat subtle as it just throws away the 2nd component of a `ScalarPair` if there is one -- without any check if this is truly a pointer or so. And indeed we used it wrong on two occasions!
So I fixed those two, and then refactored things such that everyone calls `ref_to_mplace` instead (which they did anyway, I just moved up the calls), which is the only place that should interpret a `ScalarPair` as a wide ptr -- and it checks the type first. Thus we can remove `to_scalar_ptr` and `to_meta`.
Yuki Okushi [Thu, 7 Nov 2019 00:20:44 +0000 (09:20 +0900)]
Rollup merge of #66117 - olegnn:fixed_linked_list_marker, r=RalfJung
Fixed PhantomData markers in Arc and Rc
Include owned internal structs in `PhantomData` markers in `Arc` (`PhantomData<T>` => `PhantomData<ArcInner<T>>`) and `Rc` (`PhantomData<T>` => `PhantomData<RcBox<T>>`).
Yuki Okushi [Thu, 7 Nov 2019 00:20:41 +0000 (09:20 +0900)]
Rollup merge of #66111 - RalfJung:from_raw_parts, r=Centril
improve from_raw_parts docs
Triggered by https://github.com/rust-lang/rfcs/pull/2806. Hopefully this helps clarify that joining slices across allocations is not possible in Rust currently.
Yuki Okushi [Thu, 7 Nov 2019 00:20:39 +0000 (09:20 +0900)]
Rollup merge of #66084 - petrochenkov:x86arm, r=alexcrichton
Do not require extra LLVM backends for `x.py test` to pass
For long time our testing passed with a partially built LLVM
```
[llvm]
targets = "X86;ARM"
```
, a [recent PR](https://github.com/rust-lang/rust/pull/65809) changed that.
Yuki Okushi [Thu, 7 Nov 2019 00:20:36 +0000 (09:20 +0900)]
Rollup merge of #66044 - RalfJung:uninit-lint, r=oli-obk
Improve uninit/zeroed lint
* Also warn when creating a raw pointer with a NULL vtable.
* Also identify `MaybeUninit::uninit().assume_init()` and `MaybeUninit::zeroed().assume_init()` as dangerous.
bors [Thu, 7 Nov 2019 00:10:52 +0000 (00:10 +0000)]
Auto merge of #65750 - nnethercote:cheaper-doc-comments, r=petrochenkov
Cheaper doc comments
This PR implements the idea from #60935: represent doc comments more cheaply, rather than converting them into `#[doc="..."]` attribute form. Unlike #60936 (which is about coalescing doc comments to reduce their number), this approach does not have any backwards compatibility concerns, and it eliminates about 80-90% of the current cost of doc comments (as estimated using the numbers in #60930, which eliminated the cost of doc comments entirely by treating them as normal comments).
bors [Wed, 6 Nov 2019 18:12:57 +0000 (18:12 +0000)]
Auto merge of #65728 - ecstatic-morse:promotion-const-proj, r=eddyb
Fix promotion in a `const` when projections are present
Resolves #65727.
This marks the entire local as "needs promotion" when only a projection of that local appears in a promotable context. This should only affect promotion in a `const` or `static`, not in a `fn` or `const fn`, which is handled in `promote_consts.rs`.
Dylan MacKenzie [Wed, 6 Nov 2019 15:09:16 +0000 (07:09 -0800)]
Add test for promotability in `let`
The old const-checker conservatively reset qualifs when
`IsNotPromotable` was in the return place. Unfortunately, named
variables have `IsNotPromotable`, so this could cause promotion to fail.
This should work now.
Dylan MacKenzie [Sun, 3 Nov 2019 20:49:01 +0000 (12:49 -0800)]
Remove `IsNotPromotable` and `IsNotImplicitlyPromotable`
The former was cleared from `qualifs_in_return_place`, and the latter
was never checked. `QUALIF_ERROR_BIT` no longer corresponds to a real
`Qualif`, however.
Dylan MacKenzie [Sun, 3 Nov 2019 20:36:13 +0000 (12:36 -0800)]
Remove `valid_promotion_candidates`
We no longer compare the results of
`promote_consts::validate_candidates` with
`checker.promotion_candidates`, and `promote_consts` becomes the
canonical source for determining promotability.