Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 13 pull requests #72794

Merged
merged 39 commits into from
May 31, 2020
Merged

Rollup of 13 pull requests #72794

merged 39 commits into from
May 31, 2020

Conversation

RalfJung
Copy link
Member

Successful merges:

Failed merges:

r? @ghost

euclio and others added 30 commits May 26, 2020 21:49
Adds a -Z flag to control the file path that the Gcov gcda output is
written to during runtime. This flag expects a path and filename, e.g.
-Z profile-emit=gcov/out/lib.gcda.

This works similar to GCC/Clang's -fprofile-dir flag which allows
control over the output path for gcda coverage files.
When encountering an opaque closure return type that needs to bound a
lifetime to the function's arguments, including borrows and type params,
provide appropriate suggestions that lead to working code.

Get the user from

```rust
fn foo<G, T>(g: G, dest: &mut T) -> impl FnOnce()
where
    G: Get<T>
{
    move || {
        *dest = g.get();
    }
}
```

to

```rust
fn foo<'a, G: 'a, T>(g: G, dest: &'a mut T) -> impl FnOnce() +'a
where
    G: Get<T>
{
    move || {
        *dest = g.get();
    }
}
```
…ing opaque return type

Go from

```
error[E0495]: cannot infer an appropriate lifetime due to conflicting requirements
  --> file8.rs:22:5
   |
22 | /     move || {
23 | |         *dest = g.get();
24 | |     }
   | |_____^
   |
note: first, the lifetime cannot outlive the anonymous lifetime #1 defined on the function body at 18:1...
  --> file8.rs:18:1
   |
18 | / fn bat<'a, G: 'a, T>(g: G, dest: &mut T) -> impl FnOnce() + '_ + 'a
19 | | where
20 | |     G: Get<T>
21 | | {
...  |
24 | |     }
25 | | }
   | |_^
note: ...so that the types are compatible
  --> file8.rs:22:5
   |
22 | /     move || { //~ ERROR cannot infer an appropriate lifetime
23 | |         *dest = g.get();
24 | |     }
   | |_____^
   = note: expected  `&mut T`
              found  `&mut T`
note: but, the lifetime must be valid for the lifetime `'a` as defined on the function body at 18:8...
  --> file8.rs:18:8
   |
18 | fn bat<'a, G: 'a, T>(g: G, dest: &mut T) -> impl FnOnce() + '_ + 'a
   |        ^^
note: ...so that return value is valid for the call
  --> file8.rs:18:45
   |
18 | fn bat<'a, G: 'a, T>(g: G, dest: &mut T) -> impl FnOnce() + '_ + 'a
   |                                             ^^^^^^^^^^^^^^^^^^^^^^^
```

to

```
error[E0621]: explicit lifetime required in the type of `dest`
  --> file8.rs:18:45
   |
18 | fn bat<'a, G: 'a, T>(g: G, dest: &mut T) -> impl FnOnce() + '_ + 'a
   |                                  ------     ^^^^^^^^^^^^^^^^^^^^^^^ lifetime `'a` required
   |                                  |
   |                                  help: add explicit lifetime `'a` to the type of `dest`: `&'a mut T`
   ```
Provide a suggestion for `dyn Trait + '_` when possible.
…r=nikomatsakis

Account for missing lifetime in opaque and trait object return types

When encountering an opaque closure return type that needs to bound a
lifetime to the function's arguments, including borrows and type params,
provide appropriate suggestions that lead to working code.

Get the user from

```rust
fn foo<G, T>(g: G, dest: &mut T) -> impl FnOnce()
where
    G: Get<T>
{
    move || {
        *dest = g.get();
    }
}
```

to

```rust
fn foo<'a, G: 'a, T>(g: G, dest: &'a mut T) -> impl FnOnce() +'a
where
    G: Get<T>
{
    move || {
        *dest = g.get();
    }
}
```
Improve inline asm error diagnostics

Previously we were just using the raw LLVM error output (with line, caret, etc) as the diagnostic message, which ends up looking rather out of place with our existing diagnostics.

The new diagnostics properly format the diagnostics and also take advantage of LLVM's per-line `srcloc` attribute to map an error in inline assembly directly to the relevant line of source code.

Incidentally also fixes rust-lang#71639 by disabling `srcloc` metadata during LTO builds since we don't know what crate it might have come from. We can only resolve `srcloc`s from the currently crate since it indexes into the source map for the current crate.

Fixes rust-lang#72664
Fixes rust-lang#71639

r? @petrochenkov

### Old style

```rust
#![feature(llvm_asm)]

fn main() {
    unsafe {
        let _x: i32;
        llvm_asm!(
            "mov $0, $1
             invalid_instruction $0, $1
             mov $0, $1"
             : "=&r" (_x)
             : "r" (0)
             :: "intel"
        );
    }
}
```

```
error: <inline asm>:3:14: error: invalid instruction mnemonic 'invalid_instruction'
             invalid_instruction ecx, eax
             ^~~~~~~~~~~~~~~~~~~

  --> src/main.rs:6:9
   |
6  | /         llvm_asm!(
7  | |             "mov $0, $1
8  | |              invalid_instruction $0, $1
9  | |              mov $0, $1"
...  |
12 | |              :: "intel"
13 | |         );
   | |__________^
```

### New style

```rust
#![feature(asm)]

fn main() {
    unsafe {
        asm!(
            "mov {0}, {1}
             invalid_instruction {0}, {1}
             mov {0}, {1}",
            out(reg) _,
            in(reg) 0i64,
        );
    }
}
```

```
error: invalid instruction mnemonic 'invalid_instruction'
 --> test.rs:7:14
  |
7 |              invalid_instruction {0}, {1}
  |              ^
  |
note: instantiated into assembly here
 --> <inline asm>:3:14
  |
3 |              invalid_instruction rax, rcx
  |              ^^^^^^^^^^^^^^^^^^^
```
…ewjasper

Allow types (with lifetimes/generics) in impl_lint_pass

cc rust-lang/rust-clippy#5279 (comment)

This allows to implement `LintPass` for types with lifetimes and/or generics. The only thing, I'm not sure of is the `LintPass::name` function, which now includes the lifetime(s) (which will be `'_` most of the time) in the name returned for the lint pass, if it exists. But I don't think that this should be a problem, since the `LintPass::name` is never used for output for the user (?).
…wjasper

Add -Z profile-emit=<path> for Gcov gcda output.

Adds a -Z flag to control the file path that the Gcov gcda output is
written to during runtime. This flag expects a path and filename, e.g.
-Z profile-emit=gcov/out/lib.gcda.

This works similar to GCC/Clang's -fprofile-dir flag which allows
control over the output path for gcda coverage files.
…tion-parentheses, r=estebank

Fix missing parentheses Fn notation error

Fixes  rust-lang#72611
Well, fixes the error output, I think E0658 is the right error to throw in this case so I didn't change that
…crum

rustc_session: Cleanup session creation

Noticed while reviewing rust-lang#72618.
Make bootstrap aware of relative libdir in stage0 compiler

Follows up rust-lang#72692

Fixes rust-lang#72661
rustc_lexer: Optimize shebang detection slightly

Sorry, I just couldn't resist.
It shouldn't make any difference in practice.

Also, documented a previously unnoticed case with doc comments treated as regular comments during shebang detection.
miri validation: clarify valid values of 'char'

The old text said "expected a valid unicode codepoint", which is not actually correct -- it has to be a scalar value (which is a code point that is not part of a surrogate pair).
…oshtriplett

Fix is_char_boundary documentation

Given the "start _and/or end_" wording in the original, the way I understood it was that the `str::is_char_boundary` method would also return `true` for the last byte in a UTF-8 code point sequence. (Which would have meant that for a string consisting of nothing but 1 and 2 byte UTF-8 code point sequences, it would return nothing but `true`.)

In practice the method returns `true` only for the starting byte of each sequence and the end of the string: [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e9f5fc4d6bf2f1bf57a75f3c9a180770)

I was also somewhat tempted to remove the _The start and end of the string are considered to be boundaries_, since that's implied by the first sentence, but I decided to avoid bikeshedding over it and left it as it was since it's not wrong in relation to how the method behaves.
…f-id-from-node-id, r=petrochenkov

rustdoc: remove calls to `local_def_id_from_node_id`

rustdoc calls `local_def_id_from_node_id(CRATE_NODE_ID)` when it can just creates a top level `DefId` using `DefId::local(CRATE_DEF_INDEX)`.

cc rust-lang#50928

r? @petrochenkov
@RalfJung
Copy link
Member Author

@rustbot modify labels: +rollup
@bors r+ rollup=never p=13

@bors
Copy link
Contributor

bors commented May 30, 2020

📌 Commit 581eafc has been approved by RalfJung

@rustbot rustbot added the rollup A PR which is a rollup label May 30, 2020
@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label May 30, 2020
@bors
Copy link
Contributor

bors commented May 30, 2020

⌛ Testing commit 581eafc with merge 8c5402e...

@bors
Copy link
Contributor

bors commented May 31, 2020

☀️ Test successful - checks-azure
Approved by: RalfJung
Pushing 8c5402e to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label May 31, 2020
@bors bors merged commit 8c5402e into rust-lang:master May 31, 2020
@rust-highfive
Copy link
Collaborator

📣 Toolstate changed by #72794!

Tested on commit 8c5402e.
Direct link to PR: #72794

💔 miri on windows: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung).
💔 miri on linux: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung).

rust-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request May 31, 2020
Tested on commit rust-lang/rust@8c5402e.
Direct link to PR: <rust-lang/rust#72794>

💔 miri on windows: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung).
💔 miri on linux: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung).
@RalfJung RalfJung deleted the rollup-gzs4nl4 branch May 31, 2020 08:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.