bors [Sun, 15 Nov 2020 15:39:58 +0000 (15:39 +0000)]
Auto merge of #79064 - ehuss:rustbook-logs, r=Mark-Simulacrum
Fix displaying errors when rustbook tests fail.
This ensures that output from mdbook is displayed when running the rustbook wrapper. I believe this was a regression as a result of #69115 where it was changed from running `rustdoc` directly to using rustbook.
bors [Sun, 15 Nov 2020 13:19:05 +0000 (13:19 +0000)]
Auto merge of #79070 - jonas-schievink:rollup-wacn2b8, r=jonas-schievink
Rollup of 13 pull requests
Successful merges:
- #77802 (Allow making `RUSTC_BOOTSTRAP` conditional on the crate name)
- #79004 (Add `--color` support to bootstrap)
- #79005 (cleanup: Remove `ParseSess::injected_crate_name`)
- #79016 (Make `_` an expression, to discard values in destructuring assignments)
- #79019 (astconv: extract closures into a separate trait)
- #79026 (Implement BTreeMap::retain and BTreeSet::retain)
- #79031 (Validate that locals have a corresponding `LocalDecl`)
- #79034 (rustc_resolve: Make `macro_rules` scope chain compression lazy)
- #79036 (Move Steal to rustc_data_structures.)
- #79041 (Rename clean::{ItemEnum -> ItemKind}, clean::Item::{inner -> kind})
- #79058 (Move likely/unlikely argument outside of invisible unsafe block)
- #79059 (Print 'checking cranelift artifacts' to easily separate it from other artifacts)
- #79063 (Update rustfmt to v1.4.26)
Jonas Schievink [Sun, 15 Nov 2020 12:40:03 +0000 (13:40 +0100)]
Rollup merge of #79058 - dtolnay:likelymacro, r=Mark-Simulacrum
Move likely/unlikely argument outside of invisible unsafe block
The previous `likely!`/`unlikely!` macros were unsound because it permits the caller's expr to contain arbitrary unsafe code.
```rust
pub fn huh() -> bool {
likely!(std::ptr::read(&() as *const () as *const bool))
}
```
**Before:** compiles cleanly.
**After:**
```console
error[E0133]: call to unsafe function is unsafe and requires unsafe function or block
|
70 | likely!(std::ptr::read(&() as *const () as *const bool))
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function
|
= note: consult the function's documentation for information on how to avoid undefined behavior
```
Jonas Schievink [Sun, 15 Nov 2020 12:39:54 +0000 (13:39 +0100)]
Rollup merge of #79026 - mbrubeck:btree_retain, r=m-ou-se
Implement BTreeMap::retain and BTreeSet::retain
Adds new methods `BTreeMap::retain` and `BTreeSet::retain`. These are implemented on top of `drain_filter` (#70530).
The API of these methods is identical to `HashMap::retain` and `HashSet::retain`, which were implemented in #39560 and stabilized in #36648. The docs and tests are also copied from HashMap/HashSet.
The new methods are unstable, behind the `btree_retain` feature gate, with tracking issue #79025. See also rust-lang/rfcs#1338.
Jonas Schievink [Sun, 15 Nov 2020 12:39:50 +0000 (13:39 +0100)]
Rollup merge of #79019 - lcnr:generic-arg-validation, r=petrochenkov
astconv: extract closures into a separate trait
Am currently looking into completely removing `check_generic_arg_count` and `create_substs_for_generic_args` was somewhat difficult to understand for me so I moved these closures into a trait.
This should not have changed the behavior of any of these methods
Jonas Schievink [Sun, 15 Nov 2020 12:39:48 +0000 (13:39 +0100)]
Rollup merge of #79016 - fanzier:underscore-expressions, r=petrochenkov
Make `_` an expression, to discard values in destructuring assignments
This is the third and final step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909, tracking issue: #71126). This PR is the third and final part of #71156, which was split up to allow for easier review.
With this PR, an underscore `_` is parsed as an expression but is allowed *only* on the left-hand side of a destructuring assignment. There it simply discards a value, similarly to the wildcard `_` in patterns. For instance,
```rust
(a, _) = (1, 2)
```
will simply assign 1 to `a` and discard the 2. Note that for consistency,
```
_ = foo
```
is also allowed and equivalent to just `foo`.
Thanks to ````@varkor```` who helped with the implementation, particularly around pre-expansion gating.
Jonas Schievink [Sun, 15 Nov 2020 12:39:43 +0000 (13:39 +0100)]
Rollup merge of #77802 - jyn514:bootstrap-specific, r=nikomatsakis
Allow making `RUSTC_BOOTSTRAP` conditional on the crate name
Motivation: This came up in the [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Require.20users.20to.20confirm.20they.20know.20RUSTC_.E2.80.A6.20compiler-team.23350/near/208403962) for https://github.com/rust-lang/compiler-team/issues/350.
See also https://github.com/rust-lang/cargo/pull/6608#issuecomment-458546258; this implements https://github.com/rust-lang/cargo/issues/6627.
The goal is for this to eventually allow prohibiting setting `RUSTC_BOOTSTRAP` in build.rs (https://github.com/rust-lang/cargo/issues/7088).
## User-facing changes
- `RUSTC_BOOTSTRAP=1` still works; there is no current plan to remove this.
- Things like `RUSTC_BOOTSTRAP=0` no longer activate nightly features. In practice this shouldn't be a big deal, since `RUSTC_BOOTSTRAP` is the opposite of stable and everyone uses `RUSTC_BOOTSTRAP=1` anyway.
- `RUSTC_BOOTSTRAP=x` will enable nightly features only for crate `x`.
- `RUSTC_BOOTSTRAP=x,y` will enable nightly features only for crates `x` and `y`.
## Implementation changes
The main change is that `UnstableOptions::from_environment` now requires
an (optional) crate name. If the crate name is unknown (`None`), then the new feature is not available and you still have to use `RUSTC_BOOTSTRAP=1`. In practice this means the feature is only available for `--crate-name`, not for `#![crate_name]`; I'm interested in supporting the second but I'm not sure how.
Other major changes:
- Added `Session::is_nightly_build()`, which uses the `crate_name` of
the session
- Added `nightly_options::match_is_nightly_build`, a convenience method
for looking up `--crate-name` from CLI arguments.
`Session::is_nightly_build()`should be preferred where possible, since
it will take into account `#![crate_name]` (I think).
- Added `unstable_features` to `rustdoc::RenderOptions`
I'm not sure whether this counts as T-compiler or T-lang; _technically_ RUSTC_BOOTSTRAP is an implementation detail, but it's been used so much it seems like this counts as a language change too.
r? `@joshtriplett`
cc `@Mark-Simulacrum` `@hsivonen`
Joshua Nelson [Sun, 15 Nov 2020 12:05:46 +0000 (07:05 -0500)]
Get rid of `Class::None`
This is mostly me learning the codebase, so feel free to close the PR.
It does have the small benefit that we statically know rustdoc isn't
generating useless `span`s, though.
bors [Sun, 15 Nov 2020 02:21:18 +0000 (02:21 +0000)]
Auto merge of #79065 - Dylan-DPC:rollup-gag1drk, r=Dylan-DPC
Rollup of 15 pull requests
Successful merges:
- #78352 (Do not call `unwrap` with `signatures` option enabled)
- #78590 (refactor: removing alloc::collections::vec_deque ignore-tidy-filelength)
- #78848 (Bump minimal supported LLVM version to 9)
- #78856 (Explicitly checking for or-pattern before test)
- #78948 (test: add `()=()=()=...` to weird-exprs.rs)
- #78962 (Add a test for r# identifiers)
- #78963 (Added some unit tests as requested)
- #78966 (Never inline C variadics, cold functions, functions with incompatible attributes ...)
- #78968 (Include llvm-as in llvm-tools-preview component)
- #78969 (Normalize function type during validation)
- #78980 (Fix rustc_ast_pretty print_qpath resulting in invalid macro input)
- #78986 (Avoid installing external LLVM dylibs)
- #78988 (Fix an intrinsic invocation on threaded wasm)
- #78993 (rustc_target: Fix dash vs underscore mismatches in option names)
- #79013 (Clean up outdated `use_once_payload` pretty printer comment)
Dylan DPC [Sun, 15 Nov 2020 02:03:01 +0000 (03:03 +0100)]
Rollup merge of #79013 - jryans:cleanup-use-once-pretty-comment, r=Mark-Simulacrum
Clean up outdated `use_once_payload` pretty printer comment
While reading some parts of the pretty printer code, I noticed this old comment
which seemed out of place. The `use_once_payload` this outdated comment mentions
was removed in 2017 in 40f03a1e0d6702add1922f82d716d5b2c23a59f0, so this
completes the work by removing the comment.
Dylan DPC [Sun, 15 Nov 2020 02:02:55 +0000 (03:02 +0100)]
Rollup merge of #78986 - Mark-Simulacrum:fix-llvm, r=alexcrichton
Avoid installing external LLVM dylibs
If the LLVM was externally provided, then we don't currently copy artifacts into
the sysroot. This is not necessarily the right choice (in particular, it will
require the LLVM dylib to be in the linker's load path at runtime), but the
common use case for external LLVMs is distribution provided LLVMs, and in that
case they're usually in the standard search path (e.g., /usr/lib) and copying
them here is going to cause problems as we may end up with the wrong files and
isn't what distributions want.
This behavior may be revisited in the future though.
Dylan DPC [Sun, 15 Nov 2020 02:02:53 +0000 (03:02 +0100)]
Rollup merge of #78980 - thiolliere:gui-fix-qpath, r=estebank
Fix rustc_ast_pretty print_qpath resulting in invalid macro input
related https://github.com/rust-lang/rust/issues/76874 (third case)
### Issue:
The input for a procedural macro is incorrect, for the rust code:
```rust
mod m {
pub trait Tr {
type Ts: super::Tu;
}
}
trait Tu {
fn dummy() { }
}
#[may_proc_macro]
fn foo() {
<T as m::Tr>::Ts::dummy();
}
```
the macro will get the input:
```rust
fn foo() {
<T as m::Tr>::dummy();
}
```
Thus `Ts` has disappeared.
### Fix:
This is due to invalid pretty print of qpath. This PR fix it.
Dylan DPC [Sun, 15 Nov 2020 02:02:51 +0000 (03:02 +0100)]
Rollup merge of #78969 - tmiasko:normalize, r=davidtwco
Normalize function type during validation
During inlining, the callee body is normalized and has types revealed,
but some of locals corresponding to the arguments might come from the
caller body which is not. As a result the caller body does not pass
validation without additional normalization.
Dylan DPC [Sun, 15 Nov 2020 02:02:49 +0000 (03:02 +0100)]
Rollup merge of #78968 - zec:add-llvm-as, r=Mark-Simulacrum
Include llvm-as in llvm-tools-preview component
Including `llvm-as` adds the ability to include assembly language fragments that can be inlined using LTO while making sure the correct version of LLVM is always used.
This is pretty much self contained, but depending on feedback and timing, I may have a chance to add a few more unit tests requested against `counters.rs`. I'm looking at those now.
Dylan DPC [Sun, 15 Nov 2020 02:02:39 +0000 (03:02 +0100)]
Rollup merge of #78848 - DevJPM:ci-llvm-9, r=nikic
Bump minimal supported LLVM version to 9
This bumps the minimal tested llvm version to 9.
This should enable supporting newer LLVM features (and CPU extensions).
This was motived by #78361 having to drop features because of LLVM 8 not supporting certain CPU extensions yet.
This was declared relatively uncontroversial on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Min.20Supported.20LLVM.20Upgrade.20Process.3F/near/215957859).
Paging ````@eddyb```` because there was a comment in the [dockerfile](https://github.com/rust-lang/rust/blob/master/src/ci/docker/host-x86_64/x86_64-gnu-llvm-8/Dockerfile#L42) describing a hack (which I don't quite understand) which was also blocked by not having LLVM 9.
This PR removes the need for ignore-tidy-filelength for alloc::collections::vec_deque which is part of the issue https://github.com/rust-lang/rust/issues/60302
It is probably easiest to review this PR by looking at it commit by commit rather than looking at the overall diff.
This allows constant propagation to evaluate `size_of` and `wrapping_*`,
and unreachable propagation to propagate a call to `unreachable`.
The lowering is performed as a MIR optimization, rather than during MIR
building to preserve the special status of intrinsics with respect to
unsafety checks and promotion.
Currently enabled by default to determine the performance impact (no
significant impact expected). In practice only useful when combined with
inlining since intrinsics are rarely used directly (with exception of
`unreachable` and `discriminant_value` used by built-in derive macros).
David Tolnay [Sat, 14 Nov 2020 21:54:45 +0000 (13:54 -0800)]
Move likely/unlikely argument outside of invisible unsafe block
The previous `likely!`/`unlikely!` macros were unsound because it
permits the caller's expr to contain arbitrary unsafe code.
pub fn huh() -> bool {
likely!(std::ptr::read(&() as *const () as *const bool))
}
Before: compiles cleanly.
After:
error[E0133]: call to unsafe function is unsafe and requires unsafe function or block
|
70 | likely!(std::ptr::read(&() as *const () as *const bool))
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function
|
= note: consult the function's documentation for information on how to avoid undefined behavior
bors [Sat, 14 Nov 2020 18:03:17 +0000 (18:03 +0000)]
Auto merge of #78809 - vn-ki:fix-issue-76064, r=oli-obk
add error_occured field to ConstQualifs,
fix #76064
I wasn't sure what `in_return_place` actually did and not sure why it returns `ConstQualifs` while it's sibling functions return `bool`. So I tried to make as minimal changes to the structure as possible. Please point out whether I have to refactor it or not.
bors [Sat, 14 Nov 2020 12:01:55 +0000 (12:01 +0000)]
Auto merge of #75272 - the8472:spec-copy, r=KodrAus
specialize io::copy to use copy_file_range, splice or sendfile
Fixes #74426.
Also covers #60689 but only as an optimization instead of an official API.
The specialization only covers std-owned structs so it should avoid the problems with #71091
Currently linux-only but it should be generalizable to other unix systems that have sendfile/sosplice and similar.
There is a bit of optimization potential around the syscall count. Right now it may end up doing more syscalls than the naive copy loop when doing short (<8KiB) copies between file descriptors.
0-1 `stat` calls to identify the source file type. 0 if the type can be inferred from the struct from which the FD was extracted
𝖬 `write` to drain the `BufReader`/`BufWriter` wrappers. only happen when buffers are present. 𝖬 ≾ number of wrappers present. If there is a write buffer it may absorb the read buffer contents first so only result in a single write. Vectored writes would also be an option but that would require more invasive changes to `BufWriter`.
𝖭 `copy_file_range`/`splice`/`sendfile` until file size, EOF or the byte limit from `Take` is reached. This should generally be *much* more efficient than the read-write loop and also have other benefits such as DMA offload or extent sharing.
bors [Sat, 14 Nov 2020 04:21:56 +0000 (04:21 +0000)]
Auto merge of #78736 - petrochenkov:lazyenum, r=Aaron1011
rustc_parse: Remove optimization for 0-length streams in `collect_tokens`
The optimization conflates empty token streams with unknown token stream, which is at least suspicious, and doesn't affect performance because 0-length token streams are very rare.
This allows constant propagation to evaluate `size_of` and `wrapping_*`,
and unreachable propagation to propagate a call to `unreachable`.
The lowering is performed as a MIR optimization, rather than during MIR
building to preserve the special status of intrinsics with respect to
unsafety checks and promotion.
The8472 [Thu, 12 Nov 2020 22:39:49 +0000 (23:39 +0100)]
Always handle EOVERFLOW by falling back to the generic copy loop
Previously EOVERFLOW handling was only applied for io::copy specialization
but not for fs::copy sharing the same code.
Additionally we lower the chunk size to 1GB since we have a user report
that older kernels may return EINVAL when passing 0x8000_0000
but smaller values succeed.
The8472 [Fri, 6 Nov 2020 22:36:23 +0000 (23:36 +0100)]
do direct splice syscall and probe availability to get android builds to work
Android builds use feature level 14, the libc wrapper for splice is gated
on feature level 21+ so we have to invoke the syscall directly.
Additionally the emulator doesn't seem to support it so we also have to
add ENOSYS checks.
bors [Fri, 13 Nov 2020 20:06:46 +0000 (20:06 +0000)]
Auto merge of #78888 - richkadel:llvm-coverage-tests, r=tmandry
Fix and re-enable two coverage tests on MacOS
Note, in the coverage-reports test, the comment about MacOS was wrong.
The setting is based on config.toml llvm `optimize` setting. There
doesn't appear to be any environment variable I can check, and I
don't think we should add one. Testing the binary itself is a more
reliable way to check anyway.
For the coverage-spanview test, I removed the dependency on sed
altogether, which is much less ugly than trying to work around the
MacOS sed differences.
I tested these changes on Linux, Windows, and Mac.
bors [Fri, 13 Nov 2020 14:53:55 +0000 (14:53 +0000)]
Auto merge of #79017 - GuillaumeGomez:rollup-5orhudd, r=GuillaumeGomez
Rollup of 6 pull requests
Successful merges:
- #77151 (Add regression test for issue #76042)
- #77996 (Doc change: Remove mention of `fnv` in HashMap)
- #78463 (Add type to `ConstKind::Placeholder`)
- #78984 (Rustdoc check option)
- #78985 (add dropck test for const params)
- #78996 (add explicit test for const param promotion)
Guillaume Gomez [Fri, 13 Nov 2020 14:26:10 +0000 (15:26 +0100)]
Rollup merge of #77996 - tkaitchuck:master, r=m-ou-se
Doc change: Remove mention of `fnv` in HashMap
Disclaimer: I am the author of [aHash](https://github.com/tkaitchuck/aHash).
This changes the Rustdoc in `HashMap` from mentioning the `fnv` crate to mentioning the `aHash` crate, as an alternative `Hasher` implementation.
### Why
Fnv [has poor hash quality](https://github.com/rurban/smhasher), is [slow for larger keys](https://github.com/tkaitchuck/aHash/blob/master/compare/readme.md#speed), and does not provide dos resistance, because it is unkeyed (this can also cause [other problems](https://accidentallyquadratic.tumblr.com/post/153545455987/rust-hash-iteration-reinsertion)).
Fnv has acceptable performance for integers and has very poor performance with keys >32 bytes. This is the reason it was removed from the standard library in https://github.com/rust-lang/rust/pull/37229 .
Because regardless of which dimension you value, there are better alternatives, it does not make sense for anyone to consider using `fnv`.
The text mentioning `fnv` in the standard library continues to create confusion: https://github.com/rust-lang/hashbrown/issues/153 https://github.com/rust-lang/hashbrown/issues/9 . There are also a number of [crates using it](https://crates.io/crates/fnv/reverse_dependencies) a great many of which are hashing strings (Which is when Fnv is the [worst](https://github.com/cbreeden/fxhash#benchmarks), [possible](https://github.com/tkaitchuck/aHash#speed), [choice](http://cglab.ca/~abeinges/blah/hash-rs/).)
I think aHash makes the most sense to mention as an alternative because it is the most credible option (in my obviously biased opinion). It offers [good performance on numbers and strings](https://github.com/tkaitchuck/aHash/blob/master/compare/readme.md#speed), is [of high quality](https://github.com/tkaitchuck/aHash#hash-quality), and [provides dos resistance](https://github.com/tkaitchuck/aHash/wiki/How-aHash-is-resists-DOS-attacks). It is popular (see [stats](https://crates.io/crates/ahash)) and is the default hasher for [hashbrown](https://crates.io/crates/hashbrown) and [dashmap](https://crates.io/crates/dashmap) which are the most popular alternative hashmaps. Finally it does not have any of the [`gotcha` cases](https://github.com/tkaitchuck/aHash#fxhash) that `FxHash` suffers from. (Which is the other popular hashing option when DOS attacks are not a concern)
Signed-off-by: Tom Kaitchuck <tom.kaitchuck@emc.com>
bors [Fri, 13 Nov 2020 11:49:33 +0000 (11:49 +0000)]
Auto merge of #77990 - bugadani:copies, r=lcnr
Eliminate some temporary vectors
This PR changes `get_item_attrs` and `get_item_variances` to return iterator impls instead of vectors. On top of that, this PR replaces some seemingly unnecessary vectors with iterators or SmallVec, and also reserves space where we know (the minimum) number of elements that will be inserted. This change hopes to remove a few heap allocations and unnecessary copies.
projects / rust.git / log