qt/qtdeclarative/src/qml/jsruntime
Name Description Size Coverage
qv4argumentsobject.cpp 7252 -
qv4argumentsobject_p.h 2915 -
qv4arraybuffer.cpp 9094 -
qv4arraybuffer_p.h 5460 -
qv4arraydata.cpp 25526 -
qv4arraydata_p.h 11265 -
qv4arrayiterator.cpp 2526 -
qv4arrayiterator_p.h 1627 -
qv4arrayobject.cpp 52622 -
qv4arrayobject_p.h 6113 -
qv4atomics.cpp 8316 -
qv4atomics_p.h 2147 -
qv4booleanobject.cpp 2588 -
qv4booleanobject_p.h 1452 -
qv4compilationunitmapper.cpp 2139 -
qv4compilationunitmapper_p.h 1150 -
qv4compilationunitmapper_unix.cpp Error out early on file corruption. We assume we can read header.unitSize bytes later (even before verifying the checksum), potentially causing out-of-bound reads Also, no need to wait until checksum verification if we know beforehand that the cached unit is bogus 2807 -
qv4compilationunitmapper_win.cpp Error out early on file corruption. We assume we can read header.unitSize bytes later (even before verifying the checksum), potentially causing out-of-bound reads Also, no need to wait until checksum verification if we know beforehand that the cached unit is bogus 3624 -
qv4context.cpp 14956 -
qv4context_p.h 5249 -
qv4dataview.cpp 12567 -
qv4dataview_p.h 2775 -
qv4dateobject.cpp 56337 -
qv4dateobject_p.h 15416 -
qv4debugging.cpp 391 -
qv4debugging_p.h 1374 -
qv4domerrors.cpp 2721 -
qv4domerrors_p.h 1855 -
qv4engine.cpp 124885 -
qv4engine_p.h 40065 -
qv4enginebase_p.h 3774 -
qv4errorobject.cpp 10839 -
qv4errorobject_p.h 10566 -
qv4estable.cpp 4927 -
qv4estable_p.h 2229 -
qv4executableallocator.cpp 5769 -
qv4executableallocator_p.h 2521 -
qv4executablecompilationunit.cpp In general, we should use QV4::Scope whenever we allocate heap objects, and employ write barriers for member variables pointing to heap objects. However, ExecutableCompilationUnit is special, as it is always part of the root set. So instead of using scoped allocations and write barriers, we use a slightly different approach: We temporarily block the gc from running. Afterwards, at the end of the function we check whether the gc was already running, and mark the ExecutableCompilationUnit. This ensures that all the newly allocated objects of the compilation unit will be marked in turn. If the gc was not running, we don't have to do anything, because everything will be marked when the gc starts marking the root set at the start of a run. 24893 -
qv4executablecompilationunit_p.h 13027 -
qv4function.cpp 11873 -
qv4function_p.h 5082 -
qv4functionobject.cpp 28197 -
qv4functionobject_p.h 13773 -
qv4functiontable_noop.cpp 595 -
qv4functiontable_p.h 881 -
qv4functiontable_unix.cpp 2342 -
qv4functiontable_win64.cpp info == register number 3497 -
qv4generatorobject.cpp 10366 -
qv4generatorobject_p.h 3545 -
qv4global_p.h 7679 -
qv4globalobject.cpp 19334 -
qv4globalobject_p.h 2311 -
qv4identifierhash.cpp 3743 -
qv4identifierhash_p.h 2267 -
qv4identifierhashdata_p.h 2329 -
qv4identifiertable.cpp 7846 -
qv4identifiertable_p.h 2165 -
qv4include.cpp Documented in qv4engine.cpp 6450 -
qv4include_p.h 1819 -
qv4internalclass.cpp 25401 -
qv4internalclass_p.h 13909 -
qv4iterator.cpp 1033 -
qv4iterator_p.h 991 -
qv4jscall.cpp ! \internal Sets the arguments of JSCallData from type erased \a args based on type information provided by \a types 1499 -
qv4jscall_p.h 23084 -
qv4jsonobject.cpp begin-array = ws %x5B ws ; [ left square bracket begin-object = ws %x7B ws ; { left curly bracket end-array = ws %x5D ws ; ] right square bracket end-object = ws %x7D ws ; } right curly bracket name-separator = ws %x3A ws ; : colon value-separator = ws %x2C ws ; , comma Insignificant whitespace is allowed before or after any of the six structural characters. ws = *( %x20 / ; Space %x09 / ; Horizontal tab %x0A / ; Line feed or New line %x0D ; Carriage return ) 29353 -
qv4jsonobject_p.h 3004 -
qv4lookup.cpp 30026 -
qv4lookup_p.h 21564 -
qv4managed.cpp 3239 -
qv4managed_p.h 6859 -
qv4mapiterator.cpp 2491 -
qv4mapiterator_p.h 1563 -
qv4mapobject.cpp 13113 -
qv4mapobject_p.h 3701 -
qv4math_p.h 1895 -
qv4mathobject.cpp 15660 -
qv4mathobject_p.h 4819 -
qv4memberdata.cpp 1836 -
qv4memberdata_p.h 1533 -
qv4module.cpp 8122 -
qv4module_p.h 2041 -
qv4numberobject.cpp 10248 -
qv4numberobject_p.h 2583 -
qv4object.cpp 42277 -
qv4object_p.h 20625 -
qv4objectiterator.cpp 5005 -
qv4objectiterator_p.h 2735 -
qv4objectproto.cpp 29855 -
qv4objectproto_p.h 5230 -
qv4persistent.cpp 11909 -
qv4persistent_p.h 4818 -
qv4profiling.cpp 3595 -
qv4profiling_p.h 8092 -
qv4promiseobject.cpp 38690 -
qv4promiseobject_p.h 6906 -
qv4property_p.h 6368 -
qv4propertykey.cpp 2391 -
qv4propertykey_p.h 4097 -
qv4proxy.cpp 27737 -
qv4proxy_p.h The inheritance from FunctionObject is a hack. Regular proxy objects are no function objects. But this helps implement the proxy for function objects, where we need this and thus gives us all the virtual methods from ProxyObject without having to duplicate them. But it does require a few hacks to make sure we don't recognize regular proxy objects as function objects in the runtime. 3870 -
qv4qmetaobjectwrapper.cpp 3692 -
qv4qmetaobjectwrapper_p.h 3347 -
qv4qmlcontext.cpp 35681 -
qv4qmlcontext_p.h 4117 -
qv4qobjectwrapper.cpp ! \internal Called right before a QML-to-C++ method call is dispatched, but only when qt_v4NativeCallHookEnabled is set. An attached debugger can set a breakpoint here. \a receiverMeta is the meta object of the call receiver. 115511 -
qv4qobjectwrapper_p.h 17217 -
qv4referenceobject.cpp 25265 -
qv4referenceobject_p.h 7306 -
qv4reflect.cpp 9248 -
qv4reflect_p.h 2273 -
qv4regexp.cpp 8977 -
qv4regexp_p.h 4260 -
qv4regexpobject.cpp 35280 -
qv4regexpobject_p.h 7217 -
qv4resolvedtypereference.cpp ! \internal Returns the property cache, creating one if it doesn't already exist. The cache is not referenced. 2161 -
qv4resolvedtypereference_p.h 3453 -
qv4runtime.cpp 95170 -
qv4runtime_p.h 2836 -
qv4runtimeapi_p.h call 16531 -
qv4runtimecodegen.cpp 1481 -
qv4runtimecodegen_p.h 1229 -
qv4scopedvalue_p.h 10477 -
qv4script.cpp line 6241 -
qv4script_p.h 3211 -
qv4sequenceobject.cpp ! \class QV4::Sequence \internal A Sequence stores the contents of a sequential container and makes them acccessible to the JavaScript engine. It behaves mostly like a regular JavaScript array. The entries of the container are exposed as array elements. Sequence is a ReferenceObject. Therefore it writes back its contents to the property it was retrieved from whenever it changes. It also re-reads the property whenever that one changes. As long as a Sequence is attached to a property this way, it is the responsibility of the property's surrounding (C++) object to keep the contents valid. It has to, for example, track pointers to QObjects potentially deleted in other places so that they don't become dangling. However, the Sequence can also be detached. This happens predominantly by assigning it to a QML-declared property. In that case, it becomes the Sequence's responsibility to track its contents. To do so, it does not necessarily keep an actual instance of the original container in this case, but may rather stores its contents as actual JavaScript array elements. This includes QObjectWrappers for all QObject pointers it may contain. The contents are then marked like all JavaScript array elements when the garbage collector runs, and QObjectWrapper also guards against external deletion. There is no property to read or write back in this case, and neither does the internal container need to be updated. Therefore, the objects stored as array elements are created detached and won't read or write back. For element types that don't need to be marked, Sequence will still use the original container for storage, even in the detached case. This is usually more efficient because because it saves some data conversion. The only types that need to be marked are pointers to QObject-derived types, either stored as-is or hidden inside QVariant. Whenever the container cannot possibly hold such elements (directly or indirectly), the original container is used. 40698 -
qv4sequenceobject_p.h 7032 -
qv4setiterator.cpp 2363 -
qv4setiterator_p.h 1562 -
qv4setobject.cpp 10870 -
qv4setobject_p.h 3412 -
qv4sparsearray.cpp x y \ / \ y --> x b / \ \ a b a 11588 -
qv4sparsearray_p.h 7817 -
qv4sqlerrors.cpp 1514 -
qv4sqlerrors_p.h 963 -
qv4stackframe.cpp 2301 -
qv4stackframe_p.h 12126 -
qv4string.cpp 7219 -
qv4string_p.h 8020 -
qv4stringiterator.cpp 2094 -
qv4stringiterator_p.h 1527 -
qv4stringobject.cpp 43157 -
qv4stringobject_p.h don't init 6004 -
qv4symbol.cpp 6067 -
qv4symbol_p.h 2474 -
qv4typedarray.cpp 62873 -
qv4typedarray_p.h 8756 -
qv4urlobject.cpp 43405 -
qv4urlobject_p.h 12810 -
qv4value.cpp 8498 -
qv4value_p.h 13041 -
qv4variantassociationobject.cpp ! \class QV4::VariantAssociationObject \internal A VariantAssociationObject stores the contents of a QVariantMap or QVariantHash and makes them acccessible to the JavaScript engine. It behaves mostly like a regular JavaScript object. The entries of the QVariantMap or QVariantHash are exposed as properties. VariantAssociationObject is a ReferenceObject. Therefore it writes back its contents to the property it was retrieved from whenever it changes. It also re-reads the property whenever that one changes. As long as a VariantAssociationObject is attached to a property this way, it is the responsibility of the property's surrounding (C++) object to keep the contents valid. It has to, for example, track pointers to QObjects potentially deleted in other places so that they don't become dangling. However, the VariantAssociation can also be detached. This happens predominantly by assigning it to a QML-declared property. In that case, it becomes the VariantAssociationObject's responsibility to track its contents. To do so, it does not keep an actual QVariantMap or QVariantHash in this case, but rather stores its contents as actual JavaScript object properties. This includes QObjectWrappers for all QObject pointers it may contain. The contents are then marked like all JavaScript properties when the garbage collector runs, and QObjectWrapper also guards against external deletion. There is no property to read or write back in this case, and neither does the internal QVariantMap or QVariantHash need to be updated. Therefore, the objects stored in the individual properties are also created detached and won't read or write back. 17352 -
qv4variantassociationobject_p.h 4081 -
qv4variantobject.cpp 5113 -
qv4variantobject_p.h 2300 -
qv4vme_moth.cpp ! \internal \since 5.5 This function is called uncondionally from VME::run(). An attached debugger can set a breakpoint here to intercept calls to VME::run(). 48028 -
qv4vme_moth_p.h 1091 -
qv4vtable_p.h 12134 -