To avoid lots of follow-up errors where the root cause is a failed
prototype resolution or a prototype cycle.
Task-number: QTCREATORBUG-4952
Change-Id: Id474c8c6c152c993aca8c6c421b6d88eb1481676
Reviewed-on: http://codereview.qt.nokia.com/36
Reviewed-by: Thomas Hartmann <Thomas.Hartmann@nokia.com>
Don't underline the import if a qmldump fails,
but the typeinfo is available via a .qmltypes file. That should allow
users to 'fix' qmldump issues by shipping a .qmltypes file.
Reviewed-by: Erik Verbruggen
In QML, the current directory that holds a QML file is imported
implicitly. If it contains a qmldir file, the library is imported.
Since there is no explicit import statement, Creator can't know the URI
of this library. However, if type information is available for it
already - either through a previous dump or a qmltypes file - we can
guess the URI by looking at the contained exports.
Task-number: QTCREATORBUG-3768
The problem was that several lookup calls suddenly failed because
the actual QML types were no longer in the default scope chain. However,
the QML documentation says the type names are in the scope.
Also, 'MyComponent.' in a JS-expression context only showed the attached
properties of MyComponent and missed the enums.
With this change completion now may offers too many options, but that's
better than missing some.
This reverts parts of 490f2797f6
Reviewed-by: Leandro Melo
Having a duplicate prototype chain - once in FakeMetaObjects and once
in QmlObjectValues was unnecessary. Now FMOs don't contain references
which may allow other simplifications.
Previously they were leaked when a qmldump or the C++ exported QML
type list updated.
Just deleting the previous FakeMetaObjects is not an option, as they
might still be used in a QmlObjectValue owned by an Engine.
Reviewed-by: Erik Verbruggen
* Bind::usesQmlPrototype is now significantly more performant
* type environments are no longer hashed by filename, but rather
by Document *
* duplicate scope builds are avoided
Task-number: QTCREATORBUG-2835
Reviewed-by: Erik Verbruggen
When multiple threads share the Bind instance in a Document and do
lookup on the objects contained inside, that may trigger a new object
creation in some situations - which needs to be synchronized.
Link now caches imports. That means importing the same library (say, Qt)
from more than one file no longer creates an importing namespace for
each one. Instead, a single one is created for the instance of Link.
To make this work, the type environment in ScopeChain has been given its
own type: Interpreter::TypeEnvironment. That has the added benefit of
being able to carry meta-information about imports. You can use
TypeEnvironment::importInfo(qmlComponentName) to get information about
the import node that caused the import of the component.
Now that Contexts are cached, it needs to be copyable. However, the
ScopeChain has a QmlComponentChain member that owns resources and didn't
have a correct copy constructor or copy assignment operator.
I've made QmlComponentChain non-copyable and store a shared pointer to
an instance instead, as it will generally not change for a given
context.
Reviewed-by: Lasse Holmstedt
* If possible, create LookupContexts through SemanticInfo; it caches the
linked Context and will be faster.
* Contexts now own their Engine.
Reviewed-by: Lasse Holmstedt
