Spurious `...` warning from expect_error/warning

[nealrichardson]

It makes it harder to debug a failing test because it's misleading.

> testthat::expect_warning("no warning", "something", ignore.case = TRUE)
Error: "no warning" did not throw the expected warning.
Warning message:
1 components of `...` were not used.

We detected these problematic arguments:
* `ignore.case`

Did you misspecify an argument? 

You can even see it from a passing test:

> testthat::expect_warning("no warning", NA, ignore.case = TRUE)
Warning message:
1 components of `...` were not used.

We detected these problematic arguments:
* `ignore.case`

Did you misspecify an argument? 

[hadley]

Hmmm, are you sure this is a problem? In neither of the cases you include is ignore.case actually used, so the warning is technically correct.

[nealrichardson]

Yeah I get that it isn't technically wrong, but that isn't obvious to someone who hasn't read the source for expect_condition(). The simple reprex doesn't show why IMO it's a concern. Suppose that it's expect_warning(my_function_that_should_warn(), "my warning", ignore.case = TRUE), and it doesn't throw a warning, so I have to debug why. The ... message is misleading and sends me searching in my code for where I've specified ignore.case somewhere, or why it isn't being passed correctly. Not a critical problem of course, just not a great user experience.

[hadley]

Hmmm, I guess I could explicitly pass ignore.case explicitly so that it could be force()d in compare_messages()/expect_condition_matching(). That's a bit fiddly, but I don't see any other way to keep using ellipsis::check_dots_used(), which we do want, since it protects you from typing (e.g.) ignore_case = TRUE.