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.
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 | } }
|
```
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 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 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)
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.
bors [Tue, 6 Oct 2020 14:51:51 +0000 (14:51 +0000)]
Auto merge of #76356 - caass:hooks, r=jyn514
Add a command to install a git hook to automatically run `x.py test tidy --bless`
Some folks (such as myself) would probably find a lot of convenience in a pre-commit hook that automatically runs tidy before committing, to avoid burning CI time learning that your commit wasn't tidy.
I'm absolutely positive I have missed some stuff. I basically just got this to where you can run `./x.py run install-git-hook` and then clicked the commit button. Please let me know what else you'd like me to add before this can be merged!
khyperia [Tue, 6 Oct 2020 13:39:12 +0000 (15:39 +0200)]
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.
bors [Tue, 6 Oct 2020 12:26:54 +0000 (12:26 +0000)]
Auto merge of #73905 - matthewjasper:projection-bounds-2, r=nikomatsakis
Separate projection bounds and predicates
Follow up to #72788.
- Rename `projection_predicates` to `item_bounds`
- Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates.
- Projection candidates now have the correct nested obligations
- Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations
- Type alias impl trait types are now checked (#73035)
- `feature(generic_associated_types)` no longer changes how we handle bounds (#73816)
Matthew Jasper [Sat, 25 Jul 2020 12:41:53 +0000 (13:41 +0100)]
Avoid cycles from projection bounds
Only check the own predicates of associated types when confirming
projection candidates.
Also consider implied bounds when comparing trait and impl methods.
Matthew Jasper [Fri, 24 Jul 2020 20:59:43 +0000 (21:59 +0100)]
Avoid cycle with projections from object types
Normalizing `<dyn Iterator<Item = ()> as Iterator>::Item` no longer
requires selecting `dyn Iterator<Item = ()>: Iterator`. This was
previously worked around by using a special type-folder to normalize
things.
Matthew Jasper [Sun, 5 Jul 2020 11:16:25 +0000 (12:16 +0100)]
Avoid cycle in nested obligations for object candidate
Bounds of the form `type Future: Future<Result=Self::Result>` exist in
some ecosystem crates. To validate these bounds for trait objects we
need to normalize `Self::Result` in a way that doesn't cause a cycle.
bors [Tue, 6 Oct 2020 10:17:48 +0000 (10:17 +0000)]
Auto merge of #77594 - timvermeulen:chain_advance_by, r=scottmcm
Implement advance_by, advance_back_by for iter::Chain
Part of #77404.
This PR does two things:
- implement `Chain::advance[_back]_by` in terms of `advance[_back]_by` on `self.a` and `advance[_back]_by` on `self.b`
- change `Chain::nth[_back]` to use `advance[_back]_by` on `self.a` and `nth[_back]` on `self.b`
This ensures that `Chain::nth` can take advantage of an efficient `nth` implementation on the second iterator, in case it doesn't implement `advance_by`.
bors [Tue, 6 Oct 2020 08:05:27 +0000 (08:05 +0000)]
Auto merge of #77606 - JohnTitor:rollup-7rgahdt, r=JohnTitor
Rollup of 13 pull requests
Successful merges:
- #76388 (Add a note about the panic behavior of math operations on time objects)
- #76855 (Revamp rustdoc docs about documentation using `cfg`)
- #76995 (Reduce boilerplate with the matches! macro)
- #77228 (Add missing examples for MaybeUninit)
- #77528 (Avoid unchecked casts in net parser)
- #77534 (Disallow overriding forbid in same scope)
- #77555 (Allow anyone to set regression labels)
- #77558 (Rename bootstrap/defaults/{config.toml.PROFILE => config.PROFILE.toml})
- #77559 (Fix rustdoc warnings about invalid Rust syntax)
- #77560 (Fix LitKind's byte buffer to use refcounted slice)
- #77573 (Hint doc use convert::identity relative link)
- #77587 (Fix span for unicode escape suggestion.)
- #77591 (Record `expansion_that_defined` into crate metadata)
Yuki Okushi [Tue, 6 Oct 2020 07:26:14 +0000 (16:26 +0900)]
Rollup merge of #77587 - ehuss:unicode-escape-span, r=ecstatic-morse
Fix span for unicode escape suggestion.
If a unicode escape is missing the curly braces, the suggested fix is to add the curly braces, but the span for the fix was incorrect. It was not covering the `\u`, but the suggested text includes the `\u`, causing the resulting fix to be `"\u\u{1234}"`. This changes it so that the span includes the `\u`. An alternate fix would be to remove `\u` from the suggested fix, but I think the error message reads better if the entire escape is included.
Yuki Okushi [Tue, 6 Oct 2020 07:26:11 +0000 (16:26 +0900)]
Rollup merge of #77560 - rschoon:fix-litkind-rc-bytebuf, r=lcnr
Fix LitKind's byte buffer to use refcounted slice
While working on adding a new lint for clippy (see https://github.com/rust-lang/rust-clippy/pull/6044) for avoiding shared ownership of "mutable buffer" types (such as using `Rc<Vec<T>>` instead of `Rc<[T]>`), I noticed a type exported from rustc_ast and used by clippy gets caught by the lint. This PR fixes the exported type.
This PR includes the actual change to clippy too, but I will open a PR directly against clippy for that part (although it will currently fail to build there).
This allows these files to have okay syntax highlighting in editors, and helps avoid nagging from editors which want to suggest that I install a plugin for `*.library` files to view the `config.toml.library` or whatever.