Details
-
Technical task
-
Resolution: Unresolved
-
P1: Critical
-
None
-
f198d4e3f (dev), dd731b880 (dev), 9542b4b93 (dev), d00883499 (dev), 7dcaa6c4e (dev), f2cfadc80 (dev), 36ea70960 (dev), 711267400 (dev), afd65bf6c (dev), 610930417 (dev), 9527ad1a5 (dev), c181bf986 (dev), f062cf20c (dev), 6911a76f4 (dev), 88003c8d3 (dev)
Description
The current setup of QQmlJSRegisterContent and QQmlJSScope, mediated through QQmlJSTypeResolver is too inflexible. We come up with more and more relations between types that need to be shoehorned in there. What we actually is a graph of types. The nodes are QQmlJSScopes, and the edges are relations between them, such as:
- stored in
- generalized to
- read as
- retrieved as property x from
- retrieved as return type from call to x on
- etc
Modeling the type information as such a graph would allow us to search for relevant information in a more natural way, without dragging the type resolver and all its tables around all the time.
Attachments
Issue Links
- relates to
-
QTBUG-116281 Refactor QQmlJSTypePropagator and QQmlCodeGenreator
- Reported
- mentioned in
-
Page Loading...