Tomasz Miąsko [Thu, 8 Oct 2020 00:00:00 +0000 (00:00 +0000)]
Check for non-zero return value from posix_spawn functions
The cvt function compares the argument with -1 and when equal returns a new
io::Error constructed from errno. It is used together posix_spawn_* functions.
This is incorrect. Those functions do not set errno. Instead they return
non-zero error code directly.
Check for non-zero return code and use it to construct a new io::Error.
bors [Thu, 8 Oct 2020 21:33:32 +0000 (21:33 +0000)]
Auto merge of #6117 - dtolnay:string_lit_as_bytes, r=ebroto
Downgrade string_lit_as_bytes to nursery
Between #1402 (regarding `to_owned`) and #4494 (regarding `impl Read`), as well as other confusion I've seen hit in my work codebase involving string_lit_as_bytes (`"...".as_bytes().into()`), I don't think this lint is at a quality to be enabled by default.
I would consider re-enabling this lint after it is updated to understand when the surrounding type information is sufficient to unsize `b"..."` to &\[u8\] without causing a type error.
As currently implemented, this lint is pushing people to write `&b"_"[..]` which is not an improvement over `"_".as_bytes()` as far as I am concerned.
---
changelog: Remove string_lit_as_bytes from default set of enabled lints
Jonas Schievink [Thu, 8 Oct 2020 21:23:19 +0000 (23:23 +0200)]
Rollup merge of #77710 - fortanix:raoul/bugfix-lvi, r=nikic
Update submodule llvm to get LVI bugfix
The LLVM LVI mitigations used register %rcs as a clobber register. This is problematic when rust uses this register to return (part of) function values. The problem was fixed upstream in:
Jonas Schievink [Thu, 8 Oct 2020 21:23:15 +0000 (23:23 +0200)]
Rollup merge of #77701 - jyn514:debug-logging, r=Mark-Simulacrum
Make `max_log_info` easily greppable (for figuring out why debug logging is disabled)
Follow-up to https://github.com/rust-lang/rust/pull/77678#issuecomment-705545608. I'll make a PR to the dev-guide shortly changing `debug = true` to `debug-logging = true` and using this text.
Ideally wouldn't be merged before https://github.com/rust-lang/rust/pull/77678, but it practice it won't hurt anything.
Jonas Schievink [Thu, 8 Oct 2020 21:23:12 +0000 (23:23 +0200)]
Rollup merge of #77663 - HeroicKatora:regression-tests-27675-object-safe, r=Aaron1011
Add compile fail test for issue 27675
A recently merged PR (#73905) strengthened the checks on bounds of associated items. This rejects the attack path of #27675 which consisted of constructing a `dyn Trait<Item=T>` where `T` would not fulfill the bounds required on `Item` of the `Trait` behind the dyn object.
This regression test, extracted from [the weaponized instance](https://github.com/rust-lang/rust/issues/27675#issuecomment-696956878), checks that this is rejected.
Jonas Schievink [Thu, 8 Oct 2020 21:23:10 +0000 (23:23 +0200)]
Rollup merge of #77660 - nilslice:patch-1, r=jyn514
(docs): make mutex error comment consistent with codebase
Although exceptionally minor, I found this stands out from other error reporting language used in doc comments. With the existence of the `failure` crate, I suppose this could be slightly ambiguous. In any case, this change brings the particular comment into a consistent state with other mentions of returning errors.
Jonas Schievink [Thu, 8 Oct 2020 21:23:08 +0000 (23:23 +0200)]
Rollup merge of #77449 - ssomers:btree_drain_filter_size_hint, r=Mark-Simulacrum
BTreeMap: comment why drain_filter's size_hint is somewhat pessimistic
The `size_hint` of the `DrainFilter` iterator doesn't adjust as you iterate. This hardly seems important to me, but there has been a comparable PR #64383 in the past. I guess a scenario is that you first iterate half the map manually and keep most of the key/value pairs in the map, and then tell the predicate to drain most of the key/value pairs and `.collect` the iterator over the remaining half of the map.
I am totally ambivalent whether this is better or not.
Replace run_compiler with RunCompiler builder pattern.
RunCompiler::new takes non-optional params, and optional
params can be set using set_*field_name* method.
finally `run` will forward all fields to `run_compiler`.
bors [Thu, 8 Oct 2020 16:56:14 +0000 (16:56 +0000)]
Auto merge of #6138 - giraffate:note_that_we_follow_rustc_no_merge_policy, r=Manishearth
Add note that we follow a rustc no merge-commit policy
I think it would be better to add a note that we follow a rustc no merge-commit policy. For example, it was mentioned at https://github.com/rust-lang/rust-clippy/pull/5694#issuecomment-641871096.
bors [Thu, 8 Oct 2020 13:38:29 +0000 (13:38 +0000)]
Auto merge of #77678 - jyn514:tracing, r=Mark-Simulacrum
Upgrade to tracing-subscriber 0.2.13
The primary motivation is to get the changes from
https://github.com/tokio-rs/tracing/pull/990. Example output:
```
$ RUSTDOC_LOG=debug rustdoc +rustc2
warning: some trace filter directives would enable traces that are disabled statically
| `debug` would enable the DEBUG level for all targets
= note: the static max level is `info`
= help: to enable DEBUG logging, remove the `max_level_info` feature
```
bors [Thu, 8 Oct 2020 11:42:24 +0000 (11:42 +0000)]
Auto merge of #77581 - ecstatic-morse:dataflow-dump-mir-graphviz, r=davidtwco
Use `pretty::create_dump_file` for dumping dataflow results
The old code wasn't incorporating promoteds into the path, meaning other `dot` files could get clobbered. Use the MIR dump infrastructure to generate paths so that this doesn't occur in the future.
Joshua Nelson [Sun, 4 Oct 2020 00:06:30 +0000 (20:06 -0400)]
Preserve the parent module of `DocFragment`s
- Add `parent_module` to `DocFragment`
- Require the `parent_module` of the item being inlined
- Preserve the hir_id for ExternCrates so rustdoc can find the parent module later
- Take an optional `parent_module` for `build_impl` and `merge_attrs`.
Preserve the difference between parent modules for each doc-comment.
- Support arbitrarily many re-exports in from_ast. In retrospect this is
probably not used and could be simplified to a single
`Option<(Attrs, DefId)>`.
- Don't require the parent_module for all `impl`s, just inlined items
In particular, this will be `None` whenever the attribute is not on a
re-export.
- Only store the parent_module, not the HirId
When re-exporting a re-export, the HirId is not available. Fortunately,
`collect_intra_doc_links` doesn't actually need all the info from a
HirId, just the parent module.
bors [Thu, 8 Oct 2020 03:58:55 +0000 (03:58 +0000)]
Auto merge of #77683 - jyn514:git-hook, r=Mark-Simulacrum
Unset GIT_DIR in pre-commit hook
Works around https://github.com/rust-lang/rust/issues/77620. This won't help any other hooks you write manually, but hopefully people won't feel the need to do that now there's an 'official' one.
bors [Thu, 8 Oct 2020 01:37:27 +0000 (01:37 +0000)]
Auto merge of #75470 - estebank:bare-type-expr, r=davidtwco
Detect blocks that could be struct expr bodies
This approach lives exclusively in the parser, so struct expr bodies
that are syntactically correct on their own but are otherwise incorrect
will still emit confusing errors, like in the following case:
```rust
fn foo() -> Foo {
bar: Vec::new()
}
```
```
error[E0425]: cannot find value `bar` in this scope
--> src/file.rs:5:5
|
5 | bar: Vec::new()
| ^^^ expecting a type here because of type ascription
error[E0214]: parenthesized type parameters may only be used with a `Fn` trait
--> src/file.rs:5:15
|
5 | bar: Vec::new()
| ^^^^^ only `Fn` traits may use parentheses
error[E0107]: wrong number of type arguments: expected 1, found 0
--> src/file.rs:5:10
|
5 | bar: Vec::new()
| ^^^^^^^^^^ expected 1 type argument
```
If that field had a trailing comma, that would be a parse error and it
would trigger the new, more targetted, error:
```
error: struct literal body without path
--> file.rs:4:17
|
4 | fn foo() -> Foo {
| _________________^
5 | | bar: Vec::new(),
6 | | }
| |_^
|
help: you might have forgotten to add the struct literal inside the block
|
4 | fn foo() -> Foo { Path {
5 | bar: Vec::new(),
6 | } }
|
```
clippy_lints: Do not warn against Box parameter in C FFI
Fixes #5542.
When using C FFI, to handle pointers in parameters it is needed to
declare them as `Box` in its Rust-side signature. However, the current
linter warns against the usage of Box stating that "local variable
doesn't need to be boxed here".
This commit fixes it by ignoring functions whose Abi is Cdecl.
Joshua Nelson [Wed, 7 Oct 2020 22:45:59 +0000 (18:45 -0400)]
Upgrade to tracing 0.2.13
The primary motivation is to get the changes from
https://github.com/tokio-rs/tracing/pull/990. Example output:
```
$ RUSTDOC_LOG=debug rustdoc +rustc2
warning: some trace filter directives would enable traces that are disabled statically
| `debug` would enable the DEBUG level for all targets
= note: the static max level is `info`
= help: to enable DEBUG logging, remove the `max_level_info` feature
```
- Remove useless test
This was testing for an ICE when passing `RUST_LOG=rustc_middle`. I
noticed it because it started giving the tracing warning (because tests
are not run with debug-logging enabled). Since this bug seems unlikely
to re-occur, I just removed it altogether.
bors [Wed, 7 Oct 2020 23:10:34 +0000 (23:10 +0000)]
Auto merge of #6128 - dtolnay:rc_buffer, r=yaahc
Downgrade rc_buffer to restriction
I think Arc\<Vec\<T\>\> and Arc\<String\> and similar are a totally reasonable data structure, as observed by others in the comments on [#6044](https://github.com/rust-lang/rust-clippy/pull/6044#event-3799579830) as well. Doing `Arc::make_mut(&mut self.vec).push(...)` or `Arc::make_mut(&mut self.string).push_str("...")` is a terrific and well performing copy-on-write pattern. Linting this with an enabled-by-default <kbd>performance</kbd> lint strikes me as an unacceptable false positive balance.
As of #6090 the documentation of this lint now contains:
> **Known problems:** This pattern can be desirable ...
which should indicate that we shouldn't be linting against correct, reasonable, well-performing patterns with an enabled-by-default lint.
Mentioning #6044, #6090.
r? `@yaahc,` who reviewed the lint.
---
changelog: Remove rc_buffer from default set of enabled lints
bors [Wed, 7 Oct 2020 21:51:12 +0000 (21:51 +0000)]
Auto merge of #76985 - hbina:clone_check, r=estebank
Prevent stack overflow in deeply nested types.
Related issue #75577 (?)
Unfortunately, I am unable to test whether this actually solves the problem because apparently, 12GB RAM + 2GB swap is not enough to compile the (admittedly toy) source file.
Esteban Küber [Wed, 12 Aug 2020 22:39:15 +0000 (15:39 -0700)]
Detect blocks that could be struct expr bodies
This approach lives exclusively in the parser, so struct expr bodies
that are syntactically correct on their own but are otherwise incorrect
will still emit confusing errors, like in the following case:
```rust
fn foo() -> Foo {
bar: Vec::new()
}
```
```
error[E0425]: cannot find value `bar` in this scope
--> src/file.rs:5:5
|
5 | bar: Vec::new()
| ^^^ expecting a type here because of type ascription
error[E0214]: parenthesized type parameters may only be used with a `Fn` trait
--> src/file.rs:5:15
|
5 | bar: Vec::new()
| ^^^^^ only `Fn` traits may use parentheses
error[E0107]: wrong number of type arguments: expected 1, found 0
--> src/file.rs:5:10
|
5 | bar: Vec::new()
| ^^^^^^^^^^ expected 1 type argument
```
If that field had a trailing comma, that would be a parse error and it
would trigger the new, more targetted, error:
```
error: struct literal body without path
--> file.rs:4:17
|
4 | fn foo() -> Foo {
| _________________^
5 | | bar: Vec::new(),
6 | | }
| |_^
|
help: you might have forgotten to add the struct literal inside the block
|
4 | fn foo() -> Foo { Path {
5 | bar: Vec::new(),
6 | } }
|
```
bors [Wed, 7 Oct 2020 19:59:52 +0000 (19:59 +0000)]
Auto merge of #77464 - ecstatic-morse:const-fn-impl-trait, r=oli-obk
Give `impl Trait` in a `const fn` its own feature gate
...previously it was gated under `#![feature(const_fn)]`.
I think we actually want to do this in all const-contexts? If so, this should be `#![feature(const_impl_trait)]` instead. I don't think there's any way to make use of `impl Trait` within a `const` initializer.
bors [Wed, 7 Oct 2020 17:31:56 +0000 (17:31 +0000)]
Auto merge of #77617 - AnthonyMikh:slice_windows_no_bounds_checking, r=lcnr
Eliminate bounds checking in slice::Windows
This is how `<core::slice::Windows as Iterator>::next` looks right now:
```rust
fn next(&mut self) -> Option<&'a [T]> {
if self.size > self.v.len() {
None
} else {
let ret = Some(&self.v[..self.size]);
self.v = &self.v[1..];
ret
}
}
```
The line with `self.v = &self.v[1..];` relies on assumption that `self.v` is definitely not empty at this point. Else branch is taken when `self.size <= self.v.len()`, so `self.v` can be empty if `self.size` is zero. In practice, since `Windows` is never created directly but rather trough `[T]::windows` which panics when `size` is zero, `self.size` is never zero. However, the compiler doesn't know about this check, so it keeps the code which checks bounds and panics.
Using `NonZeroUsize` lets the compiler know about this invariant and reliably eliminate bounds checking without `unsafe` on `-O2`. Here is assembly of `Windows<'a, u32>::next` before and after this change ([goldbolt](https://godbolt.org/z/xrefzx)):
bors [Wed, 7 Oct 2020 15:37:47 +0000 (15:37 +0000)]
Auto merge of #77341 - davidtwco:issue-73427-you-might-have-meant-variant, r=estebank
resolve: improve "try using the enum's variant"
Fixes #73427.
This PR improves the "try using the enum's variant" suggestion:
- Variants in suggestions would not result in more errors (e.g. use of a struct variant is only suggested if the suggestion can trivially construct that variant). Therefore, suggestions are only emitted for variants that have no fields (since the suggestion can't know what value fields would have).
- Suggestions include the syntax for constructing the variant. If a struct or tuple variant is suggested, then it is constructed in the suggestion - unless in pattern-matching or when arguments are already provided.
- A help message is added which mentions the variants which are no longer suggested.
All of the diagnostic logic introduced by this PR is separated from the normal code path for a successful compilation.
bors [Wed, 7 Oct 2020 04:58:13 +0000 (04:58 +0000)]
Auto merge of #6120 - phansch:replace-lazy-static, r=Manishearth
Replace some lazy_static usage with once_cell feature
This replaces some `lazy_static` usage with [`SyncLazy`](https://doc.rust-lang.org/nightly/std/lazy/struct.SyncLazy.html) of the unstable `once_cell` feature.
bors [Wed, 7 Oct 2020 01:20:11 +0000 (01:20 +0000)]
Auto merge of #74194 - mbrubeck:slice-eq, r=sfackler
Add PartialEq impls for Vec <-> slice
This is a follow-up to #71660 and rust-lang/rfcs#2917 to add two more missing vec/slice PartialEq impls:
```
impl<A, B> PartialEq<[B]> for Vec<A> where A: PartialEq<B> { .. }
impl<A, B> PartialEq<Vec<B>> for [A] where A: PartialEq<B> { .. }
```
Since this is insta-stable, it should go through the `@rust-lang/libs` FCP process. Note that I used version 1.47.0 for the `stable` attribute because I assume this will not merge before the 1.46.0 branch is cut next week.
bors [Tue, 6 Oct 2020 23:07:17 +0000 (23:07 +0000)]
Auto merge of #77630 - Dylan-DPC:rollup-kfwl55z, r=Dylan-DPC
Rollup of 11 pull requests
Successful merges:
- #76784 (Add some docs to rustdoc::clean::inline and def_id functions)
- #76911 (fix VecDeque::iter_mut aliasing issues)
- #77400 (Fix suggestions for x.py setup)
- #77515 (Update to chalk 0.31)
- #77568 (inliner: use caller param_env)
- #77571 (Use matches! for core::char methods)
- #77582 (Move `EarlyOtherwiseBranch` to mir-opt-level 2)
- #77590 (Update RLS and Rustfmt)
- #77605 (Fix rustc_def_path to show the full path and not the trimmed one)
- #77614 (Let backends access span information)
- #77624 (Add c as a shorthand check alternative for new options #77603)
bors [Tue, 6 Oct 2020 22:33:57 +0000 (22:33 +0000)]
Auto merge of #6127 - ebroto:reinstate_forbid_restriction, r=flip1995
Reinstate test for forbid(clippy::restriction)
In [this commit](https://github.com/rust-lang/rust-clippy/pull/6126/commits/5747c15961da9d2d0b0dd775174d39f3b5961597) coming from rust-lang/rust (#6126) the test for `#![forbid(clippy::restriction)]` was removed because some restriction lints were being allowed after the forbid.
This change reinstates the test for `forbid` by using a separate file.
Dylan DPC [Tue, 6 Oct 2020 22:16:14 +0000 (00:16 +0200)]
Rollup merge of #77614 - khyperia:set_span, r=eddyb
Let backends access span information
Sometimes, a backend may need to emit warnings, errors, or otherwise need to know the span of the current item in a basic block. So, add a `set_span` method to give the backend that information.
The `set_source_location` method already partially does this, however, it's disabled when debug info is disabled. There needs to be a way to unconditionally provide the span.
Dylan DPC [Tue, 6 Oct 2020 22:16:03 +0000 (00:16 +0200)]
Rollup merge of #77515 - jackh726:chalk-0.31, r=matthewjasper
Update to chalk 0.31
Gonna assign @nikomatsakis to the review here, but since he is pretty busy recently, if anyone else wants to review this, that would be much appreciated.
Dylan DPC [Tue, 6 Oct 2020 22:16:01 +0000 (00:16 +0200)]
Rollup merge of #77400 - alarsyo:xpy-setup-suggestions, r=jyn514
Fix suggestions for x.py setup
#76631 introduced a new `setup` command to x.py
By default the command prompts for a profile to use:
```
Welcome to the Rust project! What do you want to do with x.py?
a) Contribute to the standard library
b) Contribute to the compiler
c) Contribute to the compiler, and also modify LLVM or codegen
d) Install Rust from source
```
and then displays command suggestions, depending on which profile was chosen. However [the mapping between chosen profile](https://github.com/rust-lang/rust/blob/9cba260df0f1c67ea3690035cd5611a7465a1560/src/bootstrap/setup.rs#L75-L85) and [suggestion](https://github.com/rust-lang/rust/blob/9cba260df0f1c67ea3690035cd5611a7465a1560/src/bootstrap/setup.rs#L42-L47) isn't exact, leading to suggestions not being shown if the user presses `c` or `d`. (because "c" is translated to "llvm" and "d" to "maintainer", but suggestions trigger for "codegen" and "user" respectively)
A more thorough refactor would stop using "strings-as-type" to make sure this kind of error doesn't happen, but it may be overkill for that kind of "script" program?
bors [Tue, 6 Oct 2020 21:11:04 +0000 (21:11 +0000)]
Auto merge of #77386 - joshtriplett:static-glibc, r=petrochenkov
Support static linking with glibc and target-feature=+crt-static
With this change, it's possible to build on a linux-gnu target and pass
RUSTFLAGS='-C target-feature=+crt-static' or the equivalent via a
`.cargo/config.toml` file, and get a statically linked executable.
Update to libc 0.2.78, which adds support for static linking with glibc.
Add `crt_static_respected` to the `linux_base` target spec.
Update `android_base` and `linux_musl_base` accordingly. Avoid enabling
crt_static_respected on Android platforms, since that hasn't been
tested.