We don't assert on warnings for tests that throw

[gaearon]

I think this shouldn't pass:

    expect(() => {
      expect(() => {
        throw new Error('haha') // no warning
      }).toWarnDev(
        'nope',
      );
    }).toThrow('haha');

but it does.

[bvaughn]

The reason the above test fails is because of this check:

react/scripts/jest/matchers/toWarnDev.js

Lines 88 to 92 in e9ba8ec

	// Any unexpected Errors thrown by the callback should fail the test.
	// This should take precedence since unexpected errors could block warnings.
	if (caughtError) {
	throw caughtError;
	}

As PR #12081 mentions:

While writing tests for unsafe async warnings, I noticed that in certain cases, errors were swallowed by the toWarnDev matcher and resulted in confusing test failures. For example, if an error prevented the code being tested from logging an expected warning- the test would fail saying that the warning hadn't been logged rather than reporting the unexpected error. I think a better approach for this is to always treat caught errors as the highest-priority reason for failing a test.

I'm not sure of the best way to handle this. If there was a way to detect this nesting combination (toWarnDev inside of a toThrow) we could explicitly error saying it's not supported, but I don't think that's possible?

[bvaughn]

Maybe I could add a lint rule to warn about the above combo?

Update: This might be trickier than I thought, since it seems like we have 3 tests that don't work if the nesting order is reversed. (When we replay failed work, the warning is logged a second time- even though we only expect it once.)