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

Fix ICE for mismatched args on target without span #48047

Merged
merged 1 commit into from
Feb 10, 2018
Merged

Fix ICE for mismatched args on target without span #48047

merged 1 commit into from
Feb 10, 2018

Conversation

etaoins
Copy link
Contributor

@etaoins etaoins commented Feb 7, 2018

Commit 7ed00ca improved our error reporting by including the target function in our error messages when there is an argument count mismatch. A simple example from the UI tests is:

error[E0593]: function is expected to take a single 2-tuple as argument, but it takes 0 arguments
  --> $DIR/closure-arg-count.rs:32:53
   |
32 |     let _it = vec![1, 2, 3].into_iter().enumerate().map(foo);
   |                                                     ^^^ expected function that takes a single 2-tuple as argument
...
44 | fn foo() {}
   | -------- takes 0 arguments

However, this assumed the target span was always available. This does not hold true if the target function is in std or another crate. A simple example from #48046 is assigning str::split to a function type with a different number of arguments.

Fix by omitting all of the labels and suggestions related to the target span when it's not found.

Fixes #48046

r? @estebank

Commit 7ed00ca improved our error reporting by including the target
function in our error messages when there is an argument count mismatch.
A simple example from the UI tests is:

```
error[E0593]: function is expected to take a single 2-tuple as argument, but it takes 0 arguments
  --> $DIR/closure-arg-count.rs:32:53
   |
32 |     let _it = vec![1, 2, 3].into_iter().enumerate().map(foo);
   |                                                     ^^^ expected function that takes a single 2-tuple as argument
...
44 | fn foo() {}
   | -------- takes 0 arguments
```

However, this assumed the target span was always available. This does
not hold true if the target function is in `std` or another crate. A
simple example from #48046 is assigning `str::split` to a function type
with a different number of arguments.

Fix by removing all of the labels and suggestions related to the target
span when it's not found.

Fixes #48046
@estebank
Copy link
Contributor

estebank commented Feb 7, 2018

@bors r+ rollup

It'd be nice if the error pointed at the argument instead:

error[E0593]: function is expected to take 1 argument, but it takes 2 arguments
  --> $DIR/closure-arg-count.rs:40:41
   |
40 |     let _it = vec![1, 2, 3].into_iter().map(usize::checked_add);
   |                                         ^^^ ------------------ takes 2 arguments
   |                                         |
   |                                         expected function that takes 1 argument

Filed #48099 for the above comment.

@bors
Copy link
Contributor

bors commented Feb 7, 2018

📌 Commit daaa9a4 has been approved by estebank

@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 Feb 7, 2018
kennytm added a commit to kennytm/rust that referenced this pull request Feb 8, 2018
…-on-target-without-span, r=estebank

Fix ICE for mismatched args on target without span

Commit 7ed00ca improved our error reporting by including the target function in our error messages when there is an argument count mismatch. A simple example from the UI tests is:

```
error[E0593]: function is expected to take a single 2-tuple as argument, but it takes 0 arguments
  --> $DIR/closure-arg-count.rs:32:53
   |
32 |     let _it = vec![1, 2, 3].into_iter().enumerate().map(foo);
   |                                                     ^^^ expected function that takes a single 2-tuple as argument
...
44 | fn foo() {}
   | -------- takes 0 arguments
```

However, this assumed the target span was always available. This does not hold true if the target function is in `std` or another crate. A simple example from rust-lang#48046 is assigning `str::split` to a function type with a different number of arguments.

Fix by omitting all of the labels and suggestions related to the target span when it's not found.

Fixes rust-lang#48046

r? @estebank
bors added a commit that referenced this pull request Feb 8, 2018
Rollup of 7 pull requests

- Successful merges: #47835, #47854, #48015, #48047, #48051, #48058, #48064
- Failed merges:
bors added a commit that referenced this pull request Feb 9, 2018
Rollup of 7 pull requests

- Successful merges: #47835, #47854, #48015, #48047, #48051, #48058, #48064
- Failed merges:
bors added a commit that referenced this pull request Feb 9, 2018
Rollup of 12 pull requests

- Successful merges: #47835, #47854, #48015, #48047, #48051, #48058, #48064, #47790, #48059, #48078, #48080, #48085
- Failed merges:
@rust-lang rust-lang deleted a comment from bors Feb 9, 2018
@rust-lang rust-lang deleted a comment from bors Feb 9, 2018
kennytm added a commit to kennytm/rust that referenced this pull request Feb 9, 2018
…-on-target-without-span, r=estebank

Fix ICE for mismatched args on target without span

Commit 7ed00ca improved our error reporting by including the target function in our error messages when there is an argument count mismatch. A simple example from the UI tests is:

```
error[E0593]: function is expected to take a single 2-tuple as argument, but it takes 0 arguments
  --> $DIR/closure-arg-count.rs:32:53
   |
32 |     let _it = vec![1, 2, 3].into_iter().enumerate().map(foo);
   |                                                     ^^^ expected function that takes a single 2-tuple as argument
...
44 | fn foo() {}
   | -------- takes 0 arguments
```

However, this assumed the target span was always available. This does not hold true if the target function is in `std` or another crate. A simple example from rust-lang#48046 is assigning `str::split` to a function type with a different number of arguments.

Fix by omitting all of the labels and suggestions related to the target span when it's not found.

Fixes rust-lang#48046

r? @estebank
bors added a commit that referenced this pull request Feb 9, 2018
Rollup of 17 pull requests

- Successful merges: #47790, #47835, #47854, #48015, #48047, #48051, #48058, #48059, #48064, #48078, #48080, #48085, #48086, #48090, #48093, #48098, #48101
- Failed merges:
kennytm added a commit to kennytm/rust that referenced this pull request Feb 10, 2018
…-on-target-without-span, r=estebank

Fix ICE for mismatched args on target without span

Commit 7ed00ca improved our error reporting by including the target function in our error messages when there is an argument count mismatch. A simple example from the UI tests is:

```
error[E0593]: function is expected to take a single 2-tuple as argument, but it takes 0 arguments
  --> $DIR/closure-arg-count.rs:32:53
   |
32 |     let _it = vec![1, 2, 3].into_iter().enumerate().map(foo);
   |                                                     ^^^ expected function that takes a single 2-tuple as argument
...
44 | fn foo() {}
   | -------- takes 0 arguments
```

However, this assumed the target span was always available. This does not hold true if the target function is in `std` or another crate. A simple example from rust-lang#48046 is assigning `str::split` to a function type with a different number of arguments.

Fix by omitting all of the labels and suggestions related to the target span when it's not found.

Fixes rust-lang#48046

r? @estebank
bors added a commit that referenced this pull request Feb 10, 2018
Rollup of 16 pull requests

- Successful merges: #47790, #47835, #47854, #48015, #48047, #48051, #48058, #48059, #48064, #48078, #48080, #48086, #48098, #48101, #48107, #48100
- Failed merges:
bors added a commit that referenced this pull request Feb 10, 2018
@bors bors merged commit daaa9a4 into rust-lang:master Feb 10, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.

3 participants