Summary: I want the change from python/typeshed#13733, so upgrade all of typeshed. One change to Any (which was broken before and is a slight improvement) and one change in tuple (which is worse, will aim to solve that on top).

Reviewed By: stroxler

Differential Revision: D72057759

fbshipit-source-id: 5882711d4cb55f2d05bd612443fde000866457b0

Summary: I want the change from python/typeshed#13733, so upgrade all of typeshed. One change to Any (which was broken before and is a slight improvement) and one change in tuple (which is worse, will aim to solve that on top).

Reviewed By: stroxler

Differential Revision: D72057759

fbshipit-source-id: 5882711d4cb55f2d05bd612443fde000866457b0

…`object.__new__`

Summary:
retain-cycle

While calculating the type of `__new__` for a given class, there's a step where we take a look at the defining class of `__new__` and determine if it's the builtin `object` class -- if it's not, some special logic needs to happen; Otherwise, we fall back to the default behavior.

To determine whether the defining class of `__new__` is `object`, we obtain the `object` class from `AnswerSolver::stdlib`, and check if the defining class of the `__new__` attribute is the same as the reference to `object` class in `stdlib`.

This approach works 99.999% of the time. But it fails in exactly one scenario: while we are calculating the type of `object.__new__` during bootstrapping. In this case, because we are bootstrapping, the bootstrapping `stdlib` won't contain a valid reference to `object` (we may actually still be in the process of constructing this object!). So the query to `stdlib.object_class_type()` would always lead to a type checker runtime crash.

With D72057759, the bootstrapping process never computes the type for `object.__new__` ([my PR](python/typeshed#13733) seems to have removed the last occurrence of `XXX = object()` in typeshed stubs, and hence there's no long any need to query the type for `object.__new__`). But this can be pretty fragile since someone may add another `XXX = object()` definition to typeshed in the future, and we may want to be a little bit more resilient against that.

This diff proposes that we check the qname of the defining class of `__new__` instead so the logic would work regardless of `stdlib` availability.

Reviewed By: rchen152

Differential Revision: D72274856

fbshipit-source-id: 180a61850684f9ab9bcc6ffc2a8213ccb0922c0f

…`object.__new__`

Summary:
retain-cycle

While calculating the type of `__new__` for a given class, there's a step where we take a look at the defining class of `__new__` and determine if it's the builtin `object` class -- if it's not, some special logic needs to happen; Otherwise, we fall back to the default behavior.

To determine whether the defining class of `__new__` is `object`, we obtain the `object` class from `AnswerSolver::stdlib`, and check if the defining class of the `__new__` attribute is the same as the reference to `object` class in `stdlib`.

This approach works 99.999% of the time. But it fails in exactly one scenario: while we are calculating the type of `object.__new__` during bootstrapping. In this case, because we are bootstrapping, the bootstrapping `stdlib` won't contain a valid reference to `object` (we may actually still be in the process of constructing this object!). So the query to `stdlib.object_class_type()` would always lead to a type checker runtime crash.

With D72057759, the bootstrapping process never computes the type for `object.__new__` ([my PR](python/typeshed#13733) seems to have removed the last occurrence of `XXX = object()` in typeshed stubs, and hence there's no long any need to query the type for `object.__new__`). But this can be pretty fragile since someone may add another `XXX = object()` definition to typeshed in the future, and we may want to be a little bit more resilient against that.

This diff proposes that we check the qname of the defining class of `__new__` instead so the logic would work regardless of `stdlib` availability.

Reviewed By: rchen152

Differential Revision: D72274856

fbshipit-source-id: 180a61850684f9ab9bcc6ffc2a8213ccb0922c0f