Skip to content

Commit

Permalink
Merge pull request #1019 from google/google_sync
Browse files Browse the repository at this point in the history
Google sync
  • Loading branch information
rchen152 committed Oct 4, 2021
2 parents 5be9b24 + 300a3d3 commit bff3736
Show file tree
Hide file tree
Showing 33 changed files with 455 additions and 287 deletions.
10 changes: 10 additions & 0 deletions CHANGELOG
@@ -1,3 +1,13 @@
Version 2021.10.04

Bug fixes:
* Call init_class instead of instantiate when adding assertIsInstance bindings.
* Use the namedtuple 'defaults' argument when generating __new__ signature.
* Do not raise a parser error for unrecognised decorators.
* Merge BaseValue.cls and BaseValue.get_class().
* Check Instance.maybe_missing_members earlier during attribute access.
* Fix a bug in matching callables with TypeVar parameters.

Version 2021.09.27

New features and updates:
Expand Down
6 changes: 3 additions & 3 deletions docs/developers/annotations.md
Expand Up @@ -150,7 +150,7 @@ the `param`s are types (possibly parametrised themselves) or lists of types.
### Conversion to abstract types

The main annotation processing code lives in the
`annotations_util.AnnotationsUtil` class (instantiated as a member of the VM).
`annotation_utils.AnnotationUtils` class (instantiated as a member of the VM).
This code has several entry points, for various annotation contexts, but the
bulk of the conversion work is done in the internal method
`_process_one_annotation()`.
Expand All @@ -170,9 +170,9 @@ various kinds of annotations, and calling itself recursively to deal with nested
annotations. The return value of `_process_one_annotation` is an
`abstract.*` object that can be applied as the python type of a variable.

The various public methods in `AnnotationsUtil` cover different contexts in
The various public methods in `AnnotationUtils` cover different contexts in
which we can encounter variable annotations while processing bytecode; search
for `self.annotations_util` in `vm.py` to see where each one is used.
for `self.annotation_utils` in `vm.py` to see where each one is used.

## Tracking local operations

Expand Down
4 changes: 2 additions & 2 deletions docs/developers/special_builtins.md
Expand Up @@ -15,7 +15,7 @@ freshness: { owner: 'mdemello' reviewed: '2020-09-18' }
* [Instances](#instances)
* [Variables and data](#variables-and-data)

<!-- Added by: rechen, at: 2021-08-10T21:18-07:00 -->
<!-- Added by: rechen, at: 2021-09-22T20:26-07:00 -->

<!--te-->

Expand Down Expand Up @@ -181,7 +181,7 @@ Pytype replicates this behaviour by providing a `StaticMethod` class, whose
`call` method takes in a function (specifically a variable whose binding is an
`abstract.InterpreterFunction` object), and returns a `StaticMethodInstance`
that wraps the original variable. `StaticMethodInstance` in turn wraps the
underlying function and provides an object whose `get_class()` method returns
underlying function and provides an object whose `cls` attribute is
`special_builtins.StaticMethod` and whose `__get__` slot returns the original
function. (The details of `StaticMethodInstance` don't matter too much for now,
but note the two-stage process by which we have achieved the desired method
Expand Down
8 changes: 4 additions & 4 deletions pytype/CMakeLists.txt
Expand Up @@ -28,7 +28,7 @@ py_library(
.abstract
.abstract_utils
.analyze
.annotations_util
.annotation_utils
.attribute
.blocks
.class_mixin
Expand Down Expand Up @@ -122,9 +122,9 @@ py_library(

py_library(
NAME
annotations_util
annotation_utils
SRCS
annotations_util.py
annotation_utils.py
DEPS
._utils
.abstract
Expand Down Expand Up @@ -510,7 +510,7 @@ py_library(
._utils
.abstract
.abstract_utils
.annotations_util
.annotation_utils
.attribute
.blocks
.class_mixin
Expand Down
2 changes: 1 addition & 1 deletion pytype/__version__.py
@@ -1,2 +1,2 @@
# pylint: skip-file
__version__ = '2021.09.27'
__version__ = '2021.10.04'

0 comments on commit bff3736

Please sign in to comment.