| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most FunctionObjects do not actually need their custom jsCall members.
They will only call the functions from the vtable anyway. FunctionObject
can therefore be split into a static and a dynamic variant. Only the
dyanmic variant needs to carry (and invoke) the extra pointer. The
jsCallWithMetaTypes pointer is completely pointless because none of the
dynamic functions actually implement it.
Furthermore, the QV4::Function and QV4::ExecutionContext pointers in
FunctionObject are only needed by actual JavaScript functions. The
builtins that like to be dynamic functions never need them. Therefore,
split out another class for this.
In the generic FunctionObject, we need the capability to decide at run
time whether the function shall be a constructor or not. Add a flag to
replace the check for jsCallAsConstructor.
Also, where we can, avoid the pessimization of checking whether a
function is a constructor before trying to call it as constructor.
Rather have the default implementation throw the exception.
As a side effect, for most functions we don't need an ExecutionContext
anymore. The engine is enough.
Task-number: QTBUG-124662
Change-Id: Iac657fa71288dd6ec230a33de2986ba3bcf4628c
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of dragging another stack value around to mark if the iterator
was done, rather pass it an offset it should jump to if so. It can then
jump over any IteratorClose instruction while the ExceptionHandler can
still point to the IteratorClose instruction.
For this to work, we also have to refrain from checking for exceptions
as part of IteratorNext or IteratorClose. If IteratorNext generates an
exception, it also jumps to the "done" label, after which we dispatch
the exception. We don't want to jump to the exception handler for other
instructions in between as that would close the iterator. The iterator
should _not_ be closed if it has just thrown an exception, though. The
same holds for IteratorClose: If it throws an exception, we don't want
to jump back to the beginning of the loop's exception handler, since
that would produce an infinite loop. We also don't want to reset the
exception handler before IteratorClose because it needs to also be reset
if the iterator does not need to be closed.
This saves quite a few instructions and stack variables on actual
iteration.
For destructuring, we have to change the execution flow a bit. We need
to first perform the iteration for non-rest parameters, saving the
results in separate stack slots. This way we can apply our new "jump if
done" behavior if the iterator runs out or produces an exception itself.
We then save the "done" state in a separate stack slot, as before.
During the assignment of the iteration results to the actual variables,
we install an exception handler, so that we can still close the iterator
if one of the initializers throws an exception. This produces a few more
instructions than before:
1. We need to set and read the "needsClose" variable explicitly rather
than having IteratorNext and IteratorDone do it implicitly.
2. We need an additional CheckException after the iteration.
3. We need an additional conditional Jump over the IteratorDone.
Everything considered, the savings we get for regular iteration and the
more consistent semantics of the instructions involved are well worth
the few extra instructions on destructuring, especially since everything
those extra instructions do was done implicitly by the iterator
instructions before.
For consistency, the IteratorNextForYieldStar instruction is refactored
to work the same way as IteratorNext: In case of either an exception or
"done" it jumps to an offset, and we refrain from individually
exception-checking each IteratorNextForYieldStart instruction.
Task-number: QTBUG-116725
Change-Id: I9e2ad4319495aecabafdbbd3dd0cbf3c6191f942
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Drop unnecessary includes detected by clangd-iwyu.
Add new includes due to the transitive includes. Also, some of the
includes were detected as unused even if they were actually in use.
In those cases, use angular brackets instead of "" which deceives
the tool not to complain.
Affected subfolders: Debugger, Compiler, JsApi, JsRuntime, Memory,
Parser
Task-number: QTBUG-106473
Change-Id: I01d996a2a2ba31cbbc5f60f5454c8f850298f528
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Pick-to: 6.4
Task-number: QTBUG-67283
Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The declarations and usage of runtime functions have seen a number of
changes:
- we don't use the array of method pointers anymore because we don't use
cross-platform AOT JITting
- the check if a method can throw a JS exception was invalid, and was
not used anymore
- value-pointer vs. const-value-ref was inconsistent
This patch cleans that up. By fixing the exception checking, we can now
use it in the baseline JIT to automatically insert those checks. To make
that work correctly, all runtime methods are in a struct, which gets
annotated to indicate if that method throws. (The old way of checking
which type of engine was used is fragile: some non-throwing methods
do not take an engine parameter at all, and those got flagged as
throwing). By using a struct, we can also get rid of a bunch of
interesting macros.
The flags in the struct (as mentioned above) can later be extended to
capture more information, e.g. if a method will change the context.
Change-Id: I1e0b9ba62a0bf538eb728b4378e2678136e29a64
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
| |
|
|
|
|
|
|
|
| |
Respect the newTarget passed into those constructors and make
sure we set up the proto chain correctly.
Change-Id: I3d12c7dbef4b33660a6715d73e9fb0f89105167a
Fixes: QTBUG-71138
Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Get rid of Primitive and move the corresponding methods
directly into Value. Mark many methods in Value as
constexpr and turn Value into a POD type again.
Keep Primitive as a pure alias to Value for source
compatibility of other modules that might be using it.
Change-Id: Icb47458947dd3482c8852e95782123ea4346f5ec
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
|
|
|
| |
Change-Id: I730f00c6fc2a5f2275b92b09994f6e27dc6a3da4
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
|
|
|
| |
Change-Id: I52c31a006b80430ea949eaac246301e51a430f89
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
|
|
|
| |
Change-Id: Id23e80fe5918ba7dc897568123bf3db4d35e9092
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
|
|
|
|
|
|
|
| |
Support the new.target meta property in the codegen, and
add support for passing the newtarget into the constructor
vtable methods and the execution context.
Change-Id: I62ea58e5e92d894035a76e35776203e9837c383b
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
|
|
|
|
|
|
|
| |
Turns out that the overloading of vtable methods and regular
ones is problematic in some cases. So let's rather make it explicit
which methods are part of the vtable, and which aren't.
Change-Id: Ifee32a26104d30f3c82bca8b5a9cdea2d4f4f526
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the duplication of code between Map and Set by placing it
in a shared location, and will hopefully be a touch more efficient than
using ArrayObject.
In a followup patch, it will get faster, too.
Note: As a bonus, this also fixed a few more test failures: forEach
wasn't handling the object being changed during iteration.
Task-number: QTBUG-68545
Change-Id: I8bf6f9c5b2de030a02ce27a23b8c1da431ffeda4
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
Like Set, for the time being, this is baseed on top of ArrayObject: two
of them, one for keys, one for values. Again, this goes against the
spirit of the spec (which requires nonlinear access), but having the API
present is at least a start, and the implementation is easily changed.
Change-Id: Idcf0ad8d92eb5daac734d52e8e2dd4c8e0dd5109
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
