Using output piping mode together with Popen.wait() leads to one as actually stated
in the documentation.
GitOrigin-RevId: bb4bbb438ca54668607a92cd77d9b5255fa3bdc5
Parser initialization is moved out of constants.py modules.
generator3.py imports modules_redeclarator.py only when it's needed.
Profiling results show that it takes about 1/4 of the total running time
in scenarios when generator3 only copies existing binary stubs.
GitOrigin-RevId: 8fa303e8449cde0ddd7bcb1241a17bb4ef91ad84
I didn't manage to reproduce the original exception with libraries from user's
logs and added extra diagnostic for such cases.
GitOrigin-RevId: f883bde89022a293f8b040376ea54702c389bf80
We accidentally restored the actual path to a binary when copying skeletons
from the cache to a specific per-sdk directory on agents. Thus, pre-built
skeletons had local agent's paths instead of the special "(pre-generated)"
placeholder. It led to them being automatically deleted on skeleton clean up
phase where we compare origin paths in skeleton headers with the actual file
system content and remove those for absent binaries.
GitOrigin-RevId: 76ea06539ae3d5813941f0e4971e3dc451fde04a
Also don't copy skeletons for such binaries from the cache to an sdk
skeletons directory (there just should be none).
GitOrigin-RevId: 8b5393112540922f583d89d101e7c2860e91fb2b
So that its functions behave identically regardless of how being invoked: either
by importing the module directly or launching generator in a separate process.
GitOrigin-RevId: a4e513a851faece624b8133cba2068a6b0e5ce82
Otherwise, it affects developers on Windows, especially if they cannot increase
maximum path length limit on older versions of OS.
GitOrigin-RevId: 785363fcbb0d39f41b53211e2cef156cb672e525
We've already done it in the opposite direction turning existing
module skeletons into packages' __init__.py while generating skeletons
for submodules. It turned out, it can happen in reverse order as well:
for "pyexpat" builtin skeletons for its submodules are generated earlier
that "pyexpat" itself if processed.
GitOrigin-RevId: 76631e901bb2476c59a0fce61c55cccc4408a9a8
It's necessary to detect their import group for Optimize Imports and
delete them on package removal afterwards.
GitOrigin-RevId: e0d7d6a25978e4fb195a5607c55ea6aeb5b0e082
Otherwise, automatic line ending conversion might affect SHA 256 hashes
calculated in test data based on its content. It allowed to uniformly
compute it both for binary and text files.
GitOrigin-RevId: b41ff089235c178b182271a81a26146cff54e053
So that its functions behave identically regardless of how being invoked: either
by importing the module directly or launching generator in a separate process.
GitOrigin-RevId: a4e513a851faece624b8133cba2068a6b0e5ce82
Otherwise, it affects developers on Windows, especially if they cannot increase
maximum path length limit on older versions of OS.
GitOrigin-RevId: 785363fcbb0d39f41b53211e2cef156cb672e525
We've already done it in the opposite direction turning existing
module skeletons into packages' __init__.py while generating skeletons
for submodules. It turned out, it can happen in reverse order as well:
for "pyexpat" builtin skeletons for its submodules are generated earlier
that "pyexpat" itself if processed.
GitOrigin-RevId: 76631e901bb2476c59a0fce61c55cccc4408a9a8
