When test runner returns code > 0 (because of test failure), our runner must do the same.
See issue description for the reason
GitOrigin-RevId: 231c9ab337e80f70872bf6e6f61a397599f18e26
The previous version of the procedure could miss breakpoints when extra `EXTENDED_ARG` instructions are added before the injected code. This happened because in some corner cases after updating the opcodes to lines mapping an `EXTENDED_ARG` instruction could land as the last instruction in a line, and the instruction which argument it extends - on another. This lead to the situation when it was impossible to detect that we have hit the next line. These changes also add the ability to trace opcodes when the `PYDEVD_TRACE_OPCODES` environment variable is set to `True` (available only for Cython) to ease the debugging of such cases in the future.
(cherry picked from commit 77399d3b7b2b9bc6aac1b85d59ae305500cb6ecb)
GitOrigin-RevId: 105bf9d3d2cc51a940b03b1cb11c07e97074048b
On platforms where "fork" is not available or not used by multiprocessing
root logger configuration is not automatically inherited and, thus, we loose
messages sent by worker processes. So as not to depend on particular
implementation of the module, e.g. by checking sys.platform or
multiprocessing.get_start_method(), we now explicitly reset and setup
logging anew in every created process.
GitOrigin-RevId: 572b5a1a77346f46421a6dd1e0ed0b1ed9c4ca6f
On the whole, such stub calls look shaggy and could probably be replaced by
plain parameterless invocations altogether. It's also doubtful why we use
them only when analyzing docstrings of non-function callables, but questioning
whether they are needed in the first place seems out of scope of the current
issue. At least we don't produce warnings while generating them anymore.
GitOrigin-RevId: 25650f121e88141df081874f346d0cff2d31e3bb
If a process was started with `-m` key (and converted to `--module` flag), this parameter will be passed to all its child processes. So we need to clear this flag in SetupHolder before patching arguments
GitOrigin-RevId: 00ae0b23fc6107bee75272a03a5bd15ca474fbc7
Because we used to call venv.create() function directly in packaging_tool.py when
creating environments we ended up using function's own default unconditionally
creating copies of executables on all platforms, including those where venv itself
creates symlinks (Linux, MacOS). Turned out, it leads to issues with locating
dynamic libraries when one attempts to create a virtualenv with MacOS 10.15 system
Python 3 interpreter. Now we call venv module directly as we already do with "pip"
relying on its default behavior and patching the only command-line flag that we
actually need -- "--without-pip".
GitOrigin-RevId: d65aaa325817933de7121225038a5cf84fa2c77a
We now access the `frame.f_locals` attribute only once. Multiple access leads to the loss of the changes we have made. We also alter the second argument of the `PyFrame_LocalsToFast()` to 1 to ensure that all the deleted variables will be wiped out from the frame locals.
(cherry picked from commit 28abff39b2c37f30651db220e8700032a629ce73)
GitOrigin-RevId: 8514da7ec187c1192ea9cdf851f89f008242fc30
It allows us to overcome a Python 3.7.2 specific regression in multiprocessing
(https://bugs.python.org/issue35797).
GitOrigin-RevId: 122543ed586e3b34317e13811b5a87d8631cec61
It's already been done so for messages on the Java side. The reason is that with
the new UI for progress indicators in the status bar the link can become too
lengthy and, on the whole, it just doesn't have much value: the trailing part
of the path is usually invisible anyway, and it's obvious that it's happening
for the current project interpreter.
GitOrigin-RevId: 1d1e9da9c1f7b92f072f5030c4bd2968c6ba464c
We used to launch the generator itself for that but it seems completely
unnecessary since these versions can only diverge in case of remote interpreters
and we forcefully update helpers on a remote on every IDE release, so they
should be always in sync.
GitOrigin-RevId: 6d22dd0c0f3c3938a1a739246c98eda2f05c1ce0
We can't consume the entire stdin in case of Docker as it would require
closing the stream which apparently is not possible.
GitOrigin-RevId: 773bc28f673bf6f23ae8d25b000429abfb1480fb
Previously versions found in sdk skeletons directory and in provided .state.json
might have affected whether we take skeletons from the cache or not.
GitOrigin-RevId: d089f0531cdcdeecfbf4318fa0743ccff524d091
It leads to indefinitely large ZIP archive and hangs up initialization
of a remote interpreter.
Ideally, we should create it in a temporary directory in the first place.
GitOrigin-RevId: 9d4dea9560c14fe253d30f82c2103907fcc5636c
