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 6 pull requests #85150

Merged
merged 19 commits into from
May 10, 2021
Merged

Rollup of 6 pull requests #85150

merged 19 commits into from
May 10, 2021

Conversation

Dylan-DPC-zz
Copy link

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

FabianWolff and others added 19 commits May 7, 2021 20:46
This warning always referenced panic! even in case of an
assert. Related to rust-lang#84656
Signed-off-by: Ian Jackson <[email protected]>
Co-authored-by: Mara Bos <[email protected]>
Fix suggestions for missing return type lifetime specifiers

This pull request aims to fix rust-lang#84592. The issue is that the current code seems to assume that there is only a single relevant span pointing to the missing lifetime, and only looks at the first one:
https://github.com/rust-lang/rust/blob/e5f83d24aee866a14753a7cedbb4e301dfe5bef5/compiler/rustc_resolve/src/late/lifetimes.rs#L2959

This is incorrect, though, and leads to incorrect error messages and invalid suggestions. For instance, the example from rust-lang#84592:
```rust
struct TwoLifetimes<'x, 'y> {
    x: &'x (),
    y: &'y (),
}

fn two_lifetimes_needed(a: &(), b: &()) -> TwoLifetimes<'_, '_> {
    TwoLifetimes { x: &(), y: &() }
}
```
currently leads to:
```
error[E0106]: missing lifetime specifiers
 --> src/main.rs:6:57
  |
6 | fn two_lifetimes_needed(a: &(), b: &()) -> TwoLifetimes<'_, '_> {
  |                            ---     ---                  ^^ expected 2 lifetime parameters
  |
  = help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `a` or `b`
help: consider introducing a named lifetime parameter
  |
6 | fn two_lifetimes_needed<'a>(a: &'a (), b: &'a ()) -> TwoLifetimes<'_<'a, 'a>, '_> {
  |                        ^^^^    ^^^^^^     ^^^^^^                  ^^^^^^^^^^
```
There are two problems:
- The error message is wrong. There is only _one_ lifetime parameter expected at the location pointed to by the error message (and another one at a separate location).
- The suggestion is incorrect and will not lead to correct code.

With the changes in this PR, I get the following output:
```
error[E0106]: missing lifetime specifiers
 --> p.rs:6:57
  |
6 | fn two_lifetimes_needed(a: &(), b: &()) -> TwoLifetimes<'_, '_> {
  |                            ---     ---                  ^^  ^^ expected named lifetime parameter
  |                                                         |
  |                                                         expected named lifetime parameter
  |
  = help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `a` or `b`
help: consider introducing a named lifetime parameter
  |
6 | fn two_lifetimes_needed<'a>(a: &'a (), b: &'a ()) -> TwoLifetimes<'a, 'a> {
  |                        ^^^^    ^^^^^^     ^^^^^^                  ^^  ^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0106`.
```
Mainly, I changed `add_missing_lifetime_specifiers_label()` to receive a _vector_ of spans (and counts) instead of just one, and adjusted its body accordingly.
Improve "panic message is not a string literal" warning

This warning always referenced panic! even in case of an
assert. Related to rust-lang#84656
Make unchecked_{add,sub,mul} inherent methods unstably const

The intrinsics are marked as being stably const (even though they're not stable by nature of being intrinsics), but the currently-unstable inherent versions are not marked as const. This fixes this inconsistency. Split out of rust-lang#85017,

r? `@oli-obk`
ensure failing promoteds in const/static bodies are handled correctly

`const`/`static` bodies are the one case where we still promote code that might fail to evaluate. Ensure that this is handled correctly; in particular, it must not fail compilation.

`src/test/ui/consts/const-eval/erroneous-const.rs` ensures that when a non-promoted fails to evaluate, we *do* show an error.

r? `@oli-obk`
Provide io::Seek::rewind

Using `Seek::seek` is slightly clumsy because of the need to write (or import) `std::io::SeekFrom` to get at `SeekStart`.  C already has `rewind` (although with broken error handling); we should have it too.

I'm motivated to do this because I've just found myself copy-pasting my 5-line extension trait between projects.

That the example ends up using `OpenOptions` makes this look like a niche use case, but it is very common to rewind temporary files.  `tempfile` isn't available for use in this example or it would have looked shorter and more natural.

If this gets a positive reception I will open a tracking issue and update the feature gate.
@rustbot rustbot added the rollup A PR which is a rollup label May 10, 2021
@Dylan-DPC-zz
Copy link
Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented May 10, 2021

📌 Commit e763401 has been approved by Dylan-DPC

@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 10, 2021
@bors
Copy link
Contributor

bors commented May 10, 2021

⌛ Testing commit e763401 with merge 266f452...

@bors
Copy link
Contributor

bors commented May 10, 2021

☀️ Test successful - checks-actions
Approved by: Dylan-DPC
Pushing 266f452 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label May 10, 2021
@bors bors merged commit 266f452 into rust-lang:master May 10, 2021
@rustbot rustbot added this to the 1.54.0 milestone May 10, 2021
@Dylan-DPC-zz Dylan-DPC-zz deleted the rollup-q26gbx3 branch May 10, 2021 21:26
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.

10 participants