Because FieldTypeAndTotality used the default Object#equals, two PyTypedDictType
instances for the same definition were not considered equivalent.
GitOrigin-RevId: a241a5199200d5c54a3ae7121e3a417aa18b4ec8
The only lexer not updated is ObjectiveC, because it is using hacky manual patching, see CPP-27237
IJ-CR-103186
GitOrigin-RevId: baf62050f2c4f3f7345c5553cb6b60bca3935ab8
null arrays still can be passed, but arrays with null elements are rejected because:
- consistency: it was very complicated (for both clients and implementation code) to understand if this particular fix could be null or not, and
- performance: filtering out null elements from the array and reallocating them back were noticeably expensive.
Currently, this assertion works inside tests only, to avoid irrecoverable failures in third-party plugins
GitOrigin-RevId: b71bc59eb811a807a0e6aae9609c368806f54869
Due to location of HtmlSyntaxInfoUtil.java we forced to create service to avoid deprecated platform dependency. This service should be removed and HtmlSyntaxInfoUtil.kt should be moved to another location.
GitOrigin-RevId: 25e7c279d69b45da927e1203d6816bd92eb4510e
The snapshots attached by the user indicate that we spend a ridiculous amount of
time collecting a file's import statements in PyResolveUtil.resolveImportedElementQNameLocally
during PSI stubs construction. The reason is that while we skip functions
and classes in a file, we naively scan through all expressions looking for
statements. Now, in this case, we stop the search at statements that cannot
possibly contain other statements. For that I introduced PyCompoundStatement
interface in our PSI hierarchy that also conveniently unifies "match"
statements with other "older" statements directly owning suite.
GitOrigin-RevId: 4282e5367cae4bb1b739ba51242b9719c68018a0
I decided in favor of naive caching via getUserData/putUserData, because
to access CachedValueManager we need a project, and there are external usages
of PythonSdkUtil.isStdLib that will need to be migrated. The benefits of
CachedValueManager are not clear for this use case, however. For skeleton files,
it should be fine not to invalidate cached data because skeletons are completely
overridden by an external process on refresh, and skeletons for different SDK
are stored separately, so recorded paths should stay the same even then.
Parsing a header twice due to concurrent access is also not a problem in this
case and UserDataHolder implementation itself is thread-safe.
GitOrigin-RevId: 31f353a489861cc1cbda3a49e277f7fd6e462e13
PyStdlibCanonicalPathProvider is called as part of PyiTypeProvider.getReferenceType
during inspection passes. It reads skeleton headers under the read action
to figure out which skeletons belong to the stdlib, blocking the EDT.
However, this path provider is actually applicable only to a handful of
private modules from the standard library, and it makes no sense to perform
this costly check for all other qualified names. Reversing the order of checks
should greatly reduce the number of such IO operations until we get rid of them.
GitOrigin-RevId: d5c2529ed0c8f34384517adacdc89a43b6960114
...and use it instead of ContentIteratorEx.Status. We need to use a similar one in VirtualFileUrlManager, so by extracting a common class we can reuse it and avoid conversion between different enums. Also, we have other enums which duplicate this one (com.intellij.ui.tree.TreeVisitor.Action, com.android.tools.idea.testing.DisposerExplorer.VisitResult, com.android.tools.profilers.cpu.systemtrace.SliceStream.EnumerationResult), they can be replaced by this one as well.
GitOrigin-RevId: 14faae1a96d565ab2ab506e42bfffb96eaf64ab0
This changeset introduces a few important changes to out type inference.
First of all, TypeVar instances, represented as PyGenericType objects
in our type system, finally have associated scope owners
(see https://peps.python.org/pep-0484/#scoping-rules-for-type-variables),
which allows to safely use type parameters with the same name in different
declarations. Absence of this feature, not only caused various subtle bugs
in type checking, but also led to occasional SOEs on type substitution
(e.g. PY-54336).
To make it work consistently across the board, I also added scope owners
to type parameters extracted from docstrings in our legacy python-skeletons
format.
Secondly, now both nominal subtyping and structural subtyping via protocols
properly take into account type parameters "fixed" on inheritance. Previously,
it was done only for receivers in methods calls and attribute reads.
It fixes PY-27707, PY-35026, PY-38897.
GitOrigin-RevId: ff4e61fb9b4aff079e67b2e5263f30552da15c63
Remove ChainIterable usages from quick documentation and replace with HtmlChunk/HtmlBuilder.
I18ize some fragments.
GitOrigin-RevId: c9b1197efcb17de92361426759a7840ee1be8e4b
