🤖 User test baselines have changed for refs/heads/master

[typescript-bot]

This test run was triggerd by a request on #33716
Please review the diff and merge if no changes are unexpected.
You can view the build log here.

cc @microsoft/typescript

[sandersn]

Need to find out why arity check got less strict

[sandersn]

not sure why our arity checking is less strict than 3.9. Did we get more consistent about arity when noImplicitAny is false.

[sandersn]

better typing of this, and uglify uses their own inheritance system. I can't tell if these errors are in functions that intended to be methods, or constructor functions.

[sandersn]

we don't understand the "instance method" pattern

var log = new EE()
log.enableProgress = function() {
  this.tracker.on(...)
}

And now with better this typing, we issue an error on 'tracker'.

[sandersn]

better this typing, and we don't understand the pattern

Minimatch.prototype.make = make
function make() {
  if (this._made) return
}

[sandersn]

Fixed nullability of optional parameters when using @param {unknown} [arg] bracket syntax.

[sandersn]

another unrecognised constructor function+method pattern

[sandersn]

Promise.config is assigned a function that contains a whole bunch of non top-level Promise.prototype.method assignments. So we don't treat a bunch of methods as constructor functions, same as the other projects in this PR.

[sandersn]

aliased var d = this defeats this-property assignment detection =(

[sandersn]

same, aliased var self = this

[sandersn]

we're now checking this and the function has an incorrect @this {Element} annotation.

[sandersn]

The arity check loosening is intentional, and undoes the new errors that arose from constructor functions being real classes, which are instantiated with this types, evading the original no-errors-for-js-signatures exception.