bors [Tue, 19 Mar 2019 18:30:21 +0000 (18:30 +0000)]
Auto merge of #57842 - gnzlbg:extract_libtest, r=gnzlbg
Move libtest out of rust-lang/rust
This is a first step towards a number of goals explained in this internals post: https://internals.rust-lang.org/t/a-path-forward-towards-re-usable-libtest-functionality-custom-test-frameworks-and-a-stable-bench-macro
This PR does not fully remove libtest from rust-lang/rust, we keep a shim that imports and re-exports the external libtest, and adds the proc_macro dependency, etc.
bors [Tue, 19 Mar 2019 14:30:42 +0000 (14:30 +0000)]
Auto merge of #59293 - Centril:rollup, r=Centril
Rollup of 11 pull requests
Successful merges:
- #56348 (Add todo!() macro)
- #57729 (extra testing of how NLL handles wildcard type `_`)
- #57847 (dbg!() without parameters)
- #58778 (Implement ExactSizeIterator for ToLowercase and ToUppercase)
- #58812 (Clarify distinction between floor() and trunc())
- #58939 (Fix a tiny error in documentation of std::pin.)
- #59116 (Be more discerning on when to attempt suggesting a comma in a macro invocation)
- #59252 (add self to mailmap)
- #59275 (Replaced self-reflective explicit types with clearer `Self` or `Self::…` in stdlib docs)
- #59280 (Stabilize refcell_map_split feature)
- #59290 (Run branch cleanup after copy prop)
Rollup merge of #59275 - regexident:docs-self, r=joshtriplett
Replaced self-reflective explicit types with clearer `Self` or `Self::…` in stdlib docs
Many docs examples use explicit types instead of the semantically more clear `Self`/`Self::…` aliases.
By using the latter it's clear that the value's type depends on either `Self`, or an associated type of `Self`, instead of some constant type. It's also more consistent (and I'd argue correct), as the current docs aren't really consistent in this, as can be seen from the diff.
This is a best effort PR, as I was basically going through the docs manually, looking for offending examples. I'm sure I missed a few. Gotta start somewhere.
Rollup merge of #57729 - pnkfelix:issue-55748-pat-types-are-constraints-on-bindings-too, r=nikomatsakis
extra testing of how NLL handles wildcard type `_`
test that wildcard type `_` is not duplicated by `type Foo<X> = (X, X);` and potentially instantiated at different types when used in type ascriptions in let bindings.
(NLL's handling of this for the type ascription *expression form* is currently broken, or at least differs from what AST-borrowck does. I'll file a separate bug about that. Its not something critical to address since that expression is guarded by `#![feature(type_ascription)]`.)
Rollup merge of #56348 - matklad:todo-macro, r=withoutboats
Add todo!() macro
The primary use-case of `todo!()` macro is to be a much easier to type
alternative to `unimplemented!()` macro.
EDIT: hide unpopular proposal about re-purposing unimplemented
<details>
However, instead of just replacing `unimplemented!()`, it gives it a
more nuanced meaning: a thing which is intentionally left
unimplemented and which should not be called at runtime. Usually,
you'd like to prevent such cases statically, but sometimes you, for
example, have to implement a trait only some methods of which are
applicable. There are examples in the wild of code doing this thing,
and in this case, the current message of `unimplemented`, "not *yet*
implemented" is slightly misleading.
With the addition of TODO, you have three nuanced choices for a
`!`-returning macro (in addition to a good-old panic we all love):
* todo!()
* unreachable!()
* unimplemented!()
Here's a rough guideline what each one means:
- `todo`: use it during development, as a "hole" or placeholder. It
might be a good idea to add a pre-commit hook which checks that
`todo` is not accidentally committed.
- `unreachable!()`: use it when your code can statically guarantee
that some situation can not happen. If you use a library and hit
`unreachable!()` in the library's code, it's definitely a bug in the
library. It's OK to have `unreachable!()` in the code base,
although, if possible, it's better to replace it with
compiler-verified exhaustive checks.
- `unimplemented!()`: use it when the type checker forces you to
handle some situation, but there's a contract that a callee must not
actually call the code. If you use a library and hit
`unimplemented!()`, it's probably a bug in your code, though
it *could* be a bug in the library (or library docs) as well. It is
ok-ish to see an `unimplemented!()` in real code, but it usually
signifies a clunky, eyebrow-rising API.
</details>
bors [Mon, 18 Mar 2019 02:56:35 +0000 (02:56 +0000)]
Auto merge of #58824 - euclio:intra-link-ambiguity, r=petrochenkov
overhaul intra-doc-link ambiguity warning
Fixes #52784.
- Makes the warning part of the `intra_doc_link_resolution_failure`
lint.
- Tightens the span to just the ambiguous link.
- Reports ambiguities across all three namespaces.
- Uses structured suggestions for disambiguation.
- Adds a test for the warnings.
bors [Sun, 17 Mar 2019 23:51:18 +0000 (23:51 +0000)]
Auto merge of #59250 - bovinebuddha:filter_ui_revision_tests, r=petrochenkov
Filter ui revision tests
Updates UI test output filtering to also filter away test annotations for revisions:
Previously filtered: //~ ERROR [XXXX]
Now also filters: //[revision]~ ERROR [XXXX]
I reckon, if we have the one, we should have the other for consistency, its lack was probably an oversight (the existence of revision testing is not really well documented...)
bors [Sun, 17 Mar 2019 11:17:03 +0000 (11:17 +0000)]
Auto merge of #59178 - oli-obk:lazy_const, r=eddyb
Revert the `LazyConst` PR
The introduction of `LazyConst` did not actually achieve the code simplicity improvements that were the main reason it was introduced. Especially in the presence of const generics, the differences between the "levels of evaluatedness" of a constant become less clear. As it can be seen by the changes in this PR, further simplifications were possible by folding `LazyConst` back into `ConstValue`. We have been able to keep all the advantages gained during the `LazyConst` refactoring (like `const_eval` not returning an interned value, thus making all the `match` code simpler and more performant).
bors [Sat, 16 Mar 2019 20:48:40 +0000 (20:48 +0000)]
Auto merge of #58899 - petrochenkov:derval2, r=estebank
Do not accidentally treat multi-segment meta-items as single-segment
Fixes https://github.com/rust-lang/rust/issues/55168 and many other regressions from https://github.com/rust-lang/rust/pull/50030
Basically, attributes like `#[any::prefix::foo]` were commonly interpreted as `#[foo]` due to `name()` successfully returning the last segment (this applies to nested things as well `#[attr(any::prefix::foo)]`).
bors [Sat, 16 Mar 2019 14:46:43 +0000 (14:46 +0000)]
Auto merge of #59226 - kennytm:rollup, r=kennytm
Rollup of 37 pull requests
Successful merges:
- #58854 (appveyor: Use VS2017 for all our images)
- #58855 (std: Spin for a global malloc lock on wasm32)
- #58873 (Fix "Auto-hide item methods documentation" setting)
- #58901 (Change `std::fs::copy` to use `copyfile` on MacOS and iOS)
- #58933 (Move alloc::prelude::* to alloc::prelude::v1, make alloc a subset of std)
- #58938 (core: ensure VaList passes improper_ctypes lint)
- #58941 (MIPS: add r6 support)
- #58949 (SGX target: Expose thread id function in os module)
- #58959 (Add release notes for PR #56243)
- #58976 (Default to integrated `rust-lld` linker for UEFI targets)
- #59009 (Fix SGX implementations of read/write_vectored.)
- #59025 (Fix generic argument lookup for Self)
- #59036 (Fix ICE in MIR pretty printing)
- #59037 (Avoid some common false positives in intra doc link checking)
- #59072 (we can now skip should_panic tests with the libtest harness)
- #59079 (add suggestions to invalid macro item error)
- #59082 (A few improvements to comments in user-facing crates)
- #59102 (Consistent naming for duration_float methods and additional f32 methods)
- #59118 (rustc: fix ICE when trait alias has bare Self)
- #59139 (Unregress using scalar unions in constants.)
- #59146 (Suggest return lifetime when there's only one named lifetime)
- #59147 (Make std time tests more robust for platform differences)
- #59152 (Stabilize Range*::contains.)
- #59156 ([wg-async-await] Add regression test for #55809.)
- #59158 (Revert "Don't generate minification variable if minification disabled")
- #59169 (Add `-Z allow_features=...` flag)
- #59173 (bootstrap: Default to a sensible llvm-suffix.)
- #59175 (Don't run test launching `echo` since that doesn't exist on Windows)
- #59180 (Use try blocks in rustc_codegen_ssa)
- #59185 (No old chestnuts in iter::repeat docs)
- #59201 (Remove restriction on isize/usize in repr(simd))
- #59204 (Output diagnostic information for rustdoc)
- #59206 (Improved test output)
- #59208 (Reduce a Code Repetition Related to Bit Operation)
- #59212 (Add x86_64 musl host to the manifest)
- #59221 (Option and Result: Add references to documentation of as_ref and as_mut)
- #59231 (Stabilize Option::copied)
kennytm [Sat, 16 Mar 2019 06:57:05 +0000 (14:57 +0800)]
Rollup merge of #59208 - kenta7777:reduce-code-repetition, r=oli-obk
Reduce a Code Repetition Related to Bit Operation
This PR is related to [#49937](https://github.com/rust-lang/rust/issues/49937).
Should I do more commits about [`FIXME(49937)`](https://github.com/rust-lang/rust/search?q=FIXME%2849937%29&unscoped_q=FIXME%2849937%29) in this PR?
kennytm [Sat, 16 Mar 2019 06:56:59 +0000 (14:56 +0800)]
Rollup merge of #59185 - lukaslueg:patch-2, r=cramertj
No old chestnuts in iter::repeat docs
The current language may be amusing, yet is just imprecise and most especially difficult to understand for someone who speaks English as a foreign language.
kennytm [Sat, 16 Mar 2019 06:56:55 +0000 (14:56 +0800)]
Rollup merge of #59173 - emilio:llvm-suffix, r=Mark-Simulacrum
bootstrap: Default to a sensible llvm-suffix.
I used version-channel-sha, hopefully that should work.
I checked that bootstrap builds, but I cannot check anything else since the llvm
build process is started from cargo, and thus calls clang, and thus I hit the
same bug I hope to fix with this change.
kennytm [Sat, 16 Mar 2019 06:56:54 +0000 (14:56 +0800)]
Rollup merge of #59169 - tmandry:allow-features-flag, r=cramertj
Add `-Z allow_features=...` flag
Adds a compiler option to allow only whitelisted features.
For projects on nightly that want to prevent feature-creep (and maybe, someday, move off of nightly). Not being able to enforce this has been a problem on Fuchsia and at other big companies.
This doesn't support filtering edition feature flags, but someone is welcome to add that if they need it.
kennytm [Sat, 16 Mar 2019 06:56:53 +0000 (14:56 +0800)]
Rollup merge of #59158 - Manishearth:fix-minification, r=GuillaumeGomez
Revert "Don't generate minification variable if minification disabled"
Reverts #58643
Fixes #59157
https://github.com/rust-lang/rust/pull/58643 made us stop generating minification variables when minification is disabled, however they may still be needed for parent crates that were generated with minification (this will always be the case for libstd and libcore)
kennytm [Sat, 16 Mar 2019 06:56:51 +0000 (14:56 +0800)]
Rollup merge of #59156 - davidtwco:issue-55809, r=nikomatsakis
[wg-async-await] Add regression test for #55809.
Fixes #55809.
This PR adds a regression test for #55809 which checks that a
overflow does not occur when evaluating a requirement for async
functions and `&mut` arguments in some specific circumstances.
kennytm [Sat, 16 Mar 2019 06:56:50 +0000 (14:56 +0800)]
Rollup merge of #59152 - smmalis37:range_contains, r=SimonSapin
Stabilize Range*::contains.
Closes https://github.com/rust-lang/rust/issues/32311. There's also a bit of rustfmt on range.rs thrown in for good measure (I forgot to turn off format-on-save in VSCode).
kennytm [Sat, 16 Mar 2019 06:56:48 +0000 (14:56 +0800)]
Rollup merge of #59147 - jethrogb:jb/time-tests, r=sfackler
Make std time tests more robust for platform differences
Previously, `time::tests::since_epoch` and `time::tests::system_time_math` would fail if the platform represents a SystemTime as unix epoch + `u64` nanoseconds.
With [`num_traits::Float`](https://docs.rs/num-traits/0.2.6/num_traits/float/trait.Float.html) we could've reduced number of methods by factor of two, but unfortunately it's not part of `std`.
kennytm [Sat, 16 Mar 2019 06:56:33 +0000 (14:56 +0800)]
Rollup merge of #59037 - Manishearth:intra-doc-false, r=QuietMisdreavus
Avoid some common false positives in intra doc link checking
The empty string case is never going to be a link. The numeric case may be a link, but if it were it would have resolved locally. It's more likely the makeshift markdown footnote notation (`[0]`, etc)
kennytm [Sat, 16 Mar 2019 06:56:30 +0000 (14:56 +0800)]
Rollup merge of #59025 - aoikonomopoulos:issue-57924, r=varkor
Fix generic argument lookup for Self
Rewrite the SelfCtor early and use the replacement Def when
calculating the path_segs.
Note that this also changes which def is seen by the code that
computes user_self_ty and is_alias_variant_ctor; I don't see a
immediate issue with that, but I'm not 100% clear on the
implications.
kennytm [Sat, 16 Mar 2019 06:56:25 +0000 (14:56 +0800)]
Rollup merge of #58976 - phil-opp:patch-2, r=alexcrichton
Default to integrated `rust-lld` linker for UEFI targets
The `x86_64-unknown-uefi` target was added in https://github.com/rust-lang/rust/pull/56769 with the linker defaulting to `lld-link`. This means that a system linker with that name is required for linking.
I think defaulting to `rust-lld`, which is shipped with Rust, is a better default for the following reasons:
- Most systems don't have `lld-link` installed, so it forces users to install it first.
- The naming of LLD executables is not standarized, so users often need to create an additional symlink before things work. For example, on Ubuntu `apt install lld` leads to an executable named `lld-link-6.0`.
- We already default to `rust-lld` for [many targets](https://github.com/rust-lang/rust/search?utf8=%E2%9C%93&q=rust-lld&type=), including embedded and WASM targets, so doing the same for UEFI crates seems consistent to me. (It even seems like `x86_64-unknown-uefi` is the [only target](https://github.com/rust-lang/rust/search?q=lld-link&unscoped_q=lld-link) that uses `lld-link`.)
cc @dvdhrm who added the target and @kkk669 who [proposed to use `rust-lld`](https://github.com/rust-lang/rust/pull/56769#issuecomment-461119648).
kennytm [Sat, 16 Mar 2019 06:56:23 +0000 (14:56 +0800)]
Rollup merge of #58949 - jethrogb:jb/sgx-thread-id, r=joshtriplett
SGX target: Expose thread id function in os module
In order to call `std::os::fortanix_sgx::usercalls::send`, you need the thread id. This exposes it through another function in `std::os::fortanix_sgx`.
I looked at how other platforms do this. On Windows and `cfg(unix)` you can get the OS handle from a `thread::JoinHandle`, but that's not sufficient, I need it for a `thread::Thread`. In the future, this functionality could be added to `thread::Thread` and this platform can follow suit.
kennytm [Sat, 16 Mar 2019 06:56:21 +0000 (14:56 +0800)]
Rollup merge of #58941 - wzssyqa:master, r=alexcrichton
MIPS: add r6 support
MIPS r6 is quite different with the previous version.
It use some new target triples:
mipsisa32r6-unknown-linux-gnu
mipsisa32r6el-unknown-linux-gnu
mipsisa64r6-unknown-linux-gnuabi64
mipsisa64r6el-unknown-linux-gnuabi64
This patch has been tested with Debian Port for mips64r6el,
and the support of these triples also is included in llvm:
https://reviews.llvm.org/rGe58c45a695f39004710b6ce940d489fee800dbd3
kennytm [Sat, 16 Mar 2019 06:56:18 +0000 (14:56 +0800)]
Rollup merge of #58933 - SimonSapin:alloc-prelude-v1, r=Amanieu
Move alloc::prelude::* to alloc::prelude::v1, make alloc a subset of std
This was one of the unresolved questions of https://github.com/rust-lang/rfcs/pull/2480. As the RFC says this is maybe not useful in the sense that we are unlikely to ever have a second version, but making the crate a true subset makes one less issue to think about if we stabilize it and later want to merge standard library crates and have Cargo feature flags to enable or disable parts of the `std` crate.
See also discussion in https://github.com/rust-lang/rust/pull/58175.
Also rename the feature gate and point to a dedicated tracking issue: https://github.com/rust-lang/rust/issues/58935