Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Google sync #1257

Merged
merged 11 commits into from Jul 19, 2022
Merged

Google sync #1257

merged 11 commits into from Jul 19, 2022

Conversation

rchen152
Copy link
Contributor

No description provided.

rchen152 and others added 10 commits July 18, 2022 13:47
I was curious and took a look at our opensource 3.11 CI results. There were two
lint warnings, so I've fixed them.

PiperOrigin-RevId: 460521319
I also realized that the last time I changed is_package, I accidentally added
an extra '.' in the .pickled extension for __init__ files (so they became
__init__..pickled), but I did this both when unpickling and when checking the
filename of the unpickled file, so it worked itself out. This has been fixed.

For #1229.

PiperOrigin-RevId: 460546845
Python 3.10 changed the way line numbers are assigned to `return` statements
within `with` blocks, to attach to the `with` statement. This follows the
actual control flow in the python interpreter, but makes it hard to report
errors attached to the right line in the source code.

We examine the AST and use the line number information from the parser to
adjust the `RETURN_VALUE` opcodes to have the same line numbers as the source
`return` statements that generated them. `RETURN_VALUE` opcodes corresponding
to implicit `return None` continue to be moved to the last line of the
function.

PiperOrigin-RevId: 460639960
…nctions.

This optimization seems to be a holdover from when pytype inferred function
argument types from function calls, which would generate multiple function
signatures that needed to be flattened into a single signature. However,
functions decorated with `typing.overload` are indistinguishable from these
generated signatures, leading to overloaded functions being flattened. Since
pytype no longer uses function call inference, Factorize is not needed.

PiperOrigin-RevId: 460788149
PiperOrigin-RevId: 460837601
IF THIS CL BROKE YOU:
This change has gone through several TGPs, but given how many files it affects,
it is highly likely a new breakage will appear in the lag between the final TGP
and submission. If the breakage you are seeing follows the following pattern,
please consider fixing forward before asking for a rollback.

Known breakage pattern:

File "<f>", line <d>, in <class>: Overriding method signature mismatch [signature-mismatch]
  Base signature: '<overridden method signature>'.
  Subclass signature: '<overriding method signature>'.
  Type mismatch for parameter '<parameter name>'.

Fix:
  Add `# pytype: disable=signature-mismatch` to the end of line <d> in file <f>.
If you have a [] id for the breakage, the []_patch tool can automatically add the directives for you:
[]

In case of emergency, you can pass `--define=PYTYPE=FALSE` to build a target
broken by pytype.

PiperOrigin-RevId: 461180641
This lets us fix some errors in 3.10 caused by pytype not descending into
functions that always raise exceptions, by adding NoReturn annotations.

Really we should use all return annotations, not just NoReturn, but this is a
minimal change to unblock us for 3.10.

PiperOrigin-RevId: 461257304
PiperOrigin-RevId: 461704026
@rchen152 rchen152 merged commit 9703f77 into main Jul 19, 2022
@rchen152 rchen152 deleted the google_sync branch July 19, 2022 00:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants