Adds ability to check for possible updates across multiple default statements

[ChrisC]

This continues from the work in #909 and implements a request by @foolip to check for possible updates across multiple default statements in the new preliminary hasSupportUpdates check.

These new test cases show what happens with multiple default statements with different combinations of test results.

The update script now logs more warnings from cases where a possible update was detected in more complex scenarios, but was not completed by the update script.

cc @foolip

[foolip]

@ChrisC let me try to summarize succinctly what it is I think we should do here:

• Define what it means for a single test result (true/false/null for a specific browser version) to "have support updates for" a BCD supports statement. We can treat that support statement as an array for simplicity, even if it's an array of one element. Silences warning logs and adds additional earlier skip check if no detected BCD updates  #909 (comment) is a sketch of this that doesn't handle version_added being "preview", true, or "≤" ranges.
• Run that test against defaultStatements before we do anything, and do nothing if there are no updates needed.
• Run all of the updating machinery, which infers support statements, etc.
• Before writing the updated JSON to disk, filter it in the same way as defaultStatements and apply the test again. Warn about cases that are still not updated which will need manual intervention.

[ChrisC]

• Define what it means for a single test result (true/false/null for a specific browser version) to "have support updates for" a BCD supports statement. We can treat that support statement as an array for simplicity, even if it's an array of one element. Silences warning logs and adds additional earlier skip check if no detected BCD updates  #909 (comment) is a sketch of this that doesn't handle version_added being "preview", true, or "≤" ranges.

@foolip Good news! I ran this sample code through the multiple-statement test case and verified that it does work 👍🏽

I think I missed that this loop continues iterating through all the statements until we find a confirmation of support per version, and only returns false after we've iterated through the array of statements without finding any matching support. That was a slightly different approach from what I tried earlier that I didn't see at first glance.

I'll go ahead and integrate this approach, add the handling for possible booleans/ "preview" values, and remove the support range utility method .

[ChrisC]

@foolip I believe I got in all of the major requested changes. Feel free to take another look at this!

[foolip]

Yeah, I agree this makes sense. It's a bit unfortunate that hasSupport is passed in, but it makes sense here. Maybe it can be refactored somehow, but I'm not sure how right now, and this works!

[foolip]

Hmm, wait, going just by the name, isn't this the original BCD data (without any modifications) and not the updated BCD data that we're about to write back to disk? It needs to be the updated data, but filtered once again to "default statements", meaning excluding things like prefixed statements, flags, etc.

[ChrisC]

Yes that's correct. Seems like I misunderstood the requirement here. We were checking the updated, filtered "default statements" before this change, so I'll walk this back.

[ChrisC]

Ok addressed here bec9963

[foolip]

I've tested this and there are now very few warnings, only 3:

warn: api.EXT_texture_compression_rgtc skipped for firefox with unresolved differences between support matrix and BCD data. Possible intervention required.
warn: api.HTMLCanvasElement.getContext.webgl2_context.options_powerPreference_parameter skipped for firefox with unresolved differences between support matrix and BCD data. Possible intervention required.
warn: api.HTMLElement.autofocus skipped for firefox with unresolved differences between support matrix and BCD data. Possible intervention required.

I took a look at the last one, and found that it was actionable and that fixing it silenced the warning:
mdn/browser-compat-data#21707

This is very nice, thanks @ChrisC!

[ChrisC]

I took a look at the last one, and found that it was actionable and that fixing it silenced the warning: mdn/browser-compat-data#21707

That's great to hear!