After e7b38952621668, AutoScrollToSourceHandler remembers the modality state which it uses for processing events on the first invocation. However, it's used in BaseStructureConfigurable instances, which are reused each time the Project Structure dialog is opened (see IJPL-21800). And then the dialog is opened for the second time, it stops processing auto-scroll events. It's not that simple to fix IJPL-21800. So as a temporary solution, an internal 'resetAlarm' function was added and called when the dialog is closed to reset the instance and ensure that it'll be recreated with the proper modality state the next time the dialog is opened.
GitOrigin-RevId: 68af8a98a7d73a50d8cbc7889e4ab9a229d3ad54
The error can happen if the log has a filter by root,
and this root is later deregistered in the project mappings.
The 'FilterModel.getFilter()' caches only non-null values.
If the filter cannot be parsed, the error is being reported multiple times.
GitOrigin-RevId: eff2dffa27e3eaf1dedf318446f403466e93f797
`dataclass_transform` support posed a number of challenges to the current
AST/PSI stubs separation in our architecture. For the standard "dataclasses"
module and the "attrs" package API, we could rely on well-known names
and defaults to recognize and preserve the information about decorator
arguments and field specifier arguments in PSI stubs. With `dataclass_transform`
however, effectively any decorator call or extending any base class can indicate
using a "magical" API that should generate dataclass-like entities.
At the moment of building PSI stubs we can't be sure, because we can't leave
the boundaries of the current file to resolve these names and determine if these
decorators and base classes are decorated themselves with `dataclass_transform`.
To support that, we instead rely on well-known keyword argument names documented
in the spec, e.g. "kw_only" or "frozen". In other words, whenever we encounter
any decorator call or a superclass list with such keyword arguments, we generate
a `PyDataclassStub` stub for the corresponding class.
The same thing is happening with class attribute initializers, i.e. whenever
we see a function call with argument such as "default" or "kw_only" in their
RHS, we generate a `PyDataclassFieldStub` for the corresponding target expression.
Both of these stub interfaces now can contain null values for the corresponding
properties if they were not specified directly in the class definition.
Finally, for the `dataclass_transform` decorator itself, a new custom decorator stub
was introduced -- `PyDataclassTransformDecoratorStub`, it preserves its keyword
arguments, such as "keyword_only_default" or "frozen_default" controlling
the default properties of generated dataclasses.
Later, when we need concluded information about specific dataclass properties,
e.g. in `PyDataclassTypeProvider` to generate a constructor signature, or in
`PyDataclassInspection`, we try to "resolve" this incomplete information from stubs
into finalized `PyDataclassParameters` and `PyDataclassFieldParameters` that
contain non-null versions of the same fields. The main entry points for that
are `resolveDataclassParameters` and `resolveDataclassFieldParameters`.
These methods additionally handle the situations where decorators, superclass
lists and field specifiers lack any keyword arguments, and thus, there were no
automatically created custom stubs for them.
All the existing usages of `PyDataclassStub` and `PyDataclassFieldStub`
were updated to operate on `PyDataclassParameters` and `PyDataclassFieldParameters`
instead.
Counterparts of the tests on various inspection checks for the standard dataclasses
definitions were added for dataclasses created with `dataclass_transform`, even
though the spec is unclear on some aspects the expected type checker semantics, e.g.
if combining "eq=False" and "order=True" or specifying both "default" and
"default_factory" for a field should be reported.
I tried to follow common sense when enabling existing checks for such arbitrary
user-defined dataclass APIs.
GitOrigin-RevId: 4180a1e32b5e4025fc4e3ed49bb8d67af0d60e66
This was raising `attempted to query hidden partition: 4, allowed parts: [0, 2, 1]` issues depending on implementation
Also update the inspection to avoid further erroneous migration
GitOrigin-RevId: 89aa306fddd8f7207766da426bce4515395a83aa
'intellij.java.guiForms.jps' is added to dependencies of the build scripts modules (to allow compiling GUI forms in the build), and if tests are located in that module, test dependencies of 'intellij.java.guiForms.jps' are included in the classpath of all modules with tests for build scripts. Because of that, for example, 'intellij.idea.ultimate.build.test' had 'intellij.java.impl' in its classpath, so when a necessary dependency (on jaxb libraries) was removed from the build script modules, 'IdeaUltimateBuildTest' didn't find that because that dependency came to its classpath via 'intellij.java.impl' module, and we got a critical problem (see IDEA-358889).
Now tests of 'intellij.java.guiForms.jps' are extracted to a separate module, so their dependencies aren't included in tests for build scripts.
GitOrigin-RevId: be6e794c5a872e1bac05cdb78822616828205fcc
`which` doesn't exist in some distribution like Arch Linux. `type` is a shell built-in, it exists anywhere and does the same job.
GitOrigin-RevId: 0706f53bf5cb1f3916656d50088d551b3b61f1bf
