The correct way to use parameters is to add them to the test name.
"-k" is also works in some cases, but it is not official nor stable.
* pytest runner reports "testname[param]" as metainfo
* we fetch param
* add "parameters" field to the pytest
* glue it with test name
GitOrigin-RevId: 56c5d93fd93a12ba5742b21af51ea04823a9d8f7
replace `public static final String X = *Bundle.message(...)` with
```public static String getX() {
return *Bundle.message(...)
}
```
Also, let's mark fields that are used in third party plugins as `@deprecated`
GitOrigin-RevId: b9d42527ed14126b84dca91b837064c306c03177
It was forgotten during implementation of IDEA-106449. Without this method
we tried to parse the whole injected reStructuredText content as a valid
Python file not surprisingly containing tons of syntax errors and then
run all the normal Python inspection over it.
GitOrigin-RevId: ed12c9c6ead90ebb0b5a083126410b2c8cbff233
* For cases when a TypedDict was defined in a separate file
* Fix race when typing near inherited TypedDict's field
GitOrigin-RevId: e19792592c744e9c5a7a7c00af847296efb11d0c
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
It is safer to add python filter explicitly, not to add it to any other configuration.
And that is already done (see PythonTracebackFilter)
GitOrigin-RevId: 883972d1694eba9b3fe7602b5348ff1022b80efc
Python inspections are defined in the Python Community plugin, not in the PyCharm IDE, since they have
to be available e.g. in IntelliJ with Python Community plugin installed.
GitOrigin-RevId: e2e2af5bade75e93a22cb07bfa37b7fbf49b0596
The logic of `PyActiveSdkConfigurable` had been slightly changed previously. This resulted in the loss of the event of setting initial SDK in "Project Interpreter" combo box.
GitOrigin-RevId: 4a435344f36f8f8a8a85bccd582746175a272656
If Console tool window was created once, it's available as action in Python plugin. But before creation it's impossible to start Python Console during debug session.
GitOrigin-RevId: cfb9ac4450246f067d70626b139d8830166d68f1
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
* Do not provide references for "open" in Django (already done by another code)
* Do not use full resolve for class and functions names. In most cases "resolve", "ManyToMany" and "ModelForm" are imported as-is, not with aliases.
GitOrigin-RevId: 8a0803e6b19482654c91186aa9754ea3d91da282
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
