Age | Commit message (Collapse) | Author |
|
When calling the FXSYS_wctof method we currently pass in -1 from
AdvanceForNumber. This tells the method to calculate the string length.
This can be slow for a formcalc string with a lot of numbers.
This CL changes the call to pass in the length of remaining data in the
original string. This takes the MSAN runtime of the case in the linked
bug from ~21seconds to ~500ms. The debug runtime goes from ~2s to
~500ms.
Bug: chromium:846104
Change-Id: Idbd19a728160f35982e21c0d97567fbbeefe667a
Reviewed-on: https://pdfium-review.googlesource.com/35210
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
This CL updates some of the formcal tests to use raw literals instead of
escaping lots of things.
Change-Id: I539063b6c98aae318147b7103a0fd84e6b76054f
Reviewed-on: https://pdfium-review.googlesource.com/34190
Commit-Queue: dsinclair <dsinclair@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
|
|
When converting a Var statement from formcalc to JS we would neglect to
add the ; if the variable was initialized. This generated invalid JS as
we'd end up with two statements smushed together.
FormCalc:
var s = ""
Previous JS:
var s = ""s = pfm....
New JS:
var s = "";
s = pfm ...
Bug: pdfium:1097
Change-Id: I8a869f07374cac68a06a487dace89699a4e5540c
Reviewed-on: https://pdfium-review.googlesource.com/34110
Commit-Queue: dsinclair <dsinclair@chromium.org>
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Henrique Nakashima <hnakashima@chromium.org>
|
|
This CL converts the WidetextBuf reference to a pointer in the formcalc
ToJavaScript methods.
Change-Id: Ia05c7255a99a2eaa3d9a57f77580969896ad90a0
Reviewed-on: https://pdfium-review.googlesource.com/32612
Reviewed-by: Henrique Nakashima <hnakashima@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
This CL switches the usage of wcstod to use the FXSYS_wcstof to
determine if a given string is a valid floating point number.
Using the internal method makes linux slightly slower (10's of ms)
makes mac a lot faster 900ms to 60ms for the test case in the bug.
The FXSYS_wcstof method has been extended to handle the parsing of
float exponents. Unittests were added for FXSYS_wcstof.
Bug: chromium:813646
Change-Id: Ie68287a336e3b95a0c0b845d5bf39db6fc82b39c
Reviewed-on: https://pdfium-review.googlesource.com/32510
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
This CL simplifies the FormCalc method call generation when converted to
JavaScript. Currently we output the same chunk of code to run the
given method on an array or object per method call. This CL pulls out
the common execution code to a pfm_method_runner function which is used
instead.
An embedder test has been added to verify that method invocation from
formcalc works correctly.
Bug: chromium:814848
Change-Id: I1ec052eab051053fedcb464d57e0e15228b8c5a2
Reviewed-on: https://pdfium-review.googlesource.com/32372
Reviewed-by: Henrique Nakashima <hnakashima@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
This CL changes the formcalc JS conversion code so that method calls no
longer generate exponential amounts of JavaScript.
Previously we'd duplicate the code to call into a method twice. This
would then generate twice once for arrays and once for other types of
object. This CL changes the code to wrap the actual method call into
a JavaScript function which will be used from both the array and
non-array calling code.
For the referenced bug, the generated JS originally needed a buffer of
365meg to generate. With this CL, it needs a buffer of 7.5k.
Bug: chromium:814840
Change-Id: Ibb5993fa52b7c13b20b325cf8848a306f82ae014
Reviewed-on: https://pdfium-review.googlesource.com/32312
Reviewed-by: Henrique Nakashima <hnakashima@chromium.org>
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
This CL modifies the formcalc transpiler to create less CFX_WideTextBuf
classes as we convert to JavaScript. This can take some pathalogical
formcal from 20sec to convert to .5sec.
Bug: chromium:834575
Change-Id: I428883297bbc3a6a325a4ab0ad51834f2f02ab82
Reviewed-on: https://pdfium-review.googlesource.com/32154
Commit-Queue: dsinclair <dsinclair@chromium.org>
Reviewed-by: Henrique Nakashima <hnakashima@chromium.org>
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
|
|
If there is remaining data after the lexer has said it's complete then
something has gone wrong while lexing the formcalc data. This CL changes
the transpiler to return an error in the case of the lexer havign extra
data.
Bug: chromium:834575
Change-Id: I8a1288a7f01cc69faf2033829d68246d815258de
Reviewed-on: https://pdfium-review.googlesource.com/32130
Commit-Queue: dsinclair <dsinclair@chromium.org>
Reviewed-by: Henrique Nakashima <hnakashima@chromium.org>
|
|
BUG=pdfium:507
Change-Id: I28eeb9a5f6d7099eef6d8e7e37d425cd4613c49c
Reviewed-on: https://pdfium-review.googlesource.com/31430
Reviewed-by: dsinclair <dsinclair@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
|
|
As currently written, the calculation of m_end will underflow
when passed a {nullptr, 0} pair as input, and m_end becomes
essentially unbounded.
Change-Id: Id3249b201c446555d9aa4fa04e6a3c94a357cd99
Reviewed-on: https://pdfium-review.googlesource.com/30230
Reviewed-by: dsinclair <dsinclair@chromium.org>
Commit-Queue: Tom Sepez <tsepez@chromium.org>
|
|
Change-Id: I0059e2ec25e90162a241a49e5d7b327c80330a33
Reviewed-on: https://pdfium-review.googlesource.com/29890
Commit-Queue: dsinclair <dsinclair@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>
|
|
This CL decreases the kMaxPostExpressions to 256. This is the number of
accessors you can attach to a single statement (e.g. foo.#A.#A.#A).
Having a very large number can cause stack overflows. The accessor does
not seem like it would expect hundreds of entries on a single element.
Bug: chromium:820688
Change-Id: I19966b43c96f5d1d02a79af127a0c96609420811
Reviewed-on: https://pdfium-review.googlesource.com/29330
Reviewed-by: Henrique Nakashima <hnakashima@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
Instances are either replaced with FXSYS_iswalpha, which calls out to
the ICU library to do the proper Unicode operations, or have been
converted to a isascii && isalpha pair, if ASCII alpha is actually
what was wanted.
BUG=pdfium:1035
Change-Id: I971ff639ee1ff818ad08793a1900a8bcbb0a3e04
Reviewed-on: https://pdfium-review.googlesource.com/28450
Reviewed-by: dsinclair <dsinclair@chromium.org>
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
|
|
A number of our character helper methods take in wide character types,
but only do tests/operations on the ASCII range of characters. As a
very quick first pass I am renaming all of the foot-gun methods to
explictly call out this behaviour, while I do a bigger
cleanup/refactor.
BUG=pdfium:1035
Change-Id: Ia035dfa1cb6812fa6d45155c4565475032c4c165
Reviewed-on: https://pdfium-review.googlesource.com/28330
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
Reviewed-by: Henrique Nakashima <hnakashima@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>
|
|
When building the formcalc parser trees we need to limit on width along
with depth. It's possible to generate a tree of a single depth but is
more then 20k nodes wide. This will eventuall cause stack overflow
issues.
This CL re-uses the depth check for the grammar expressions in which
we're extending the width of the tree we count that against our depth
check.
Bug: chromium:813346
Change-Id: I01f6567a75776a75374465eacc1ff546db46cac1
Reviewed-on: https://pdfium-review.googlesource.com/28170
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Henrique Nakashima <hnakashima@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
This Cl adds checking for the conditionals of if and elseif expressions.
If the conditional fails to parse we should return nullptr. This already
happens by accident in the if() case, but with elseif() conditions we'll
fail the ASSERT in the CXFA_FMIfExpression constructor and crash.
This CL explicitly checks for the expressions and early exists if they
failed to parse.
Bug: chromium:819509
Change-Id: I9a90182c7709c8c4c0d3ae17d6be67cb668c0c6a
Reviewed-on: https://pdfium-review.googlesource.com/28131
Commit-Queue: dsinclair <dsinclair@chromium.org>
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Henrique Nakashima <hnakashima@chromium.org>
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
|
|
This CL removes the checks for empty declaration bodies.
Change-Id: I06a8f602f49d7709bce86442cae2d38991fa5d82
Reviewed-on: https://pdfium-review.googlesource.com/27950
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
This CL refactors the signature parsing for formcalc functions.
Change-Id: I69634968ab1cbd9698a3ce3ae321e14bafe918c6
Reviewed-on: https://pdfium-review.googlesource.com/27930
Commit-Queue: dsinclair <dsinclair@chromium.org>
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
|
|
This CL cleans up the setting of m_error. In most cases we don't need to
set m_error it will be set when we bubble up the nullptr return from the
various parse methods.
The m_error was set inconsitently previously and was confusing on if it
needed to be set or not.
Change-Id: I8648b6296ef15239bd2663e6543a960b88177721
Reviewed-on: https://pdfium-review.googlesource.com/27910
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
Get things out of the .data section.
Change-Id: I375cf00186a3d5d8d10f5d147bd4b692f5db3683
Reviewed-on: https://pdfium-review.googlesource.com/27130
Commit-Queue: Tom Sepez <tsepez@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>
|
|
This CL creates a CXFA_FMAST root for the AST tree instead of
overloading the CXFA_FMFunctionDefinition. This Removes the m_global
from FunctionDefinition and simpifies the code.
Change-Id: I9347769a291ef1753539701f334cc8dd69b7187e
Reviewed-on: https://pdfium-review.googlesource.com/27590
Commit-Queue: dsinclair <dsinclair@chromium.org>
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
|
|
Change-Id: I5b81a483c57b97598a0d36ceaebc382016e95ae3
Reviewed-on: https://pdfium-review.googlesource.com/27591
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
This CL simplifies the if expression parsing. The elseif construct has
been split into its own list of IfExpressions and no longer gets
stuffed into the elseExpression. A loop was added into the output methods
for the elseif expressions, which also means we can go from having:
if () {
} else {
if () {
} else {
}
}
to
if () {
} else if () {
} else {
}
Which is a bit nicer.
Change-Id: I6edf75215500d6a32a8d7218d477b6960f03de51
Reviewed-on: https://pdfium-review.googlesource.com/27571
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
This extends the test case for slightly more coverage.
Change-Id: I97613c2d8df416b37718ff747d218dd61ea02b37
Reviewed-on: https://pdfium-review.googlesource.com/27570
Commit-Queue: dsinclair <dsinclair@chromium.org>
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
|
|
This CL makes minor clarity cleanups to the formcalc parser and attempts
to record the productions each method is processing.
Change-Id: Ie12bb55647abf06251d1734fd05d08a964a32ebc
Reviewed-on: https://pdfium-review.googlesource.com/27550
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
This CL switches the empty destructors in the FormCalc expressions to
use default.
Change-Id: I0a2ea520c89a96d29a2e2564572a7cf345f9f31a
Reviewed-on: https://pdfium-review.googlesource.com/27510
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
|
|
In all the places we call ParseBlockExpression we really mean to parse
an ExpressionList. Using ParseBlockExpression is confusing because the
formcalc grammar has a BlockExpression defined which corresponds to our
ParseDoExpression.
This CL converts the use of ParseBlockExpression into calls to
ParseExpressionList and then builds the BlockExpression class as needed.
Change-Id: Iab9b6e783f01d35df905539d4dbc20ba18a7b0f9
Reviewed-on: https://pdfium-review.googlesource.com/27470
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
The expression type is no longer used, removed.
Change-Id: I4c8b17ed1644560afd7fc87a7fb6c7d893b9de5c
Reviewed-on: https://pdfium-review.googlesource.com/27450
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
This CL combines the elseif and else output code for formcalc. This
causes an extra set of {}'s to be output in the else case but should be
syntactically the same.
Change-Id: Ie30a51efadae2034d117f4bf280b9f7abc950a23
Reviewed-on: https://pdfium-review.googlesource.com/27431
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
|
|
The if token in formcalc is an internal keyword and can not be used as
an identifier. The current if parsing code will turn if into an
identifier if it fails to find the 'then' statement after the argument
list.
This should be a failed parse instead of coverting if to an identifier
and resetting the lexer.
Change-Id: Ieebf6a1aabc27482fcaeaf7a9bd4be40fc01e9ad
Reviewed-on: https://pdfium-review.googlesource.com/27430
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
|
|
The recorded line number from the formcalc parse is never used. This Cl
removes the parameter and removes the need to pass it through all of the
constructors.
Change-Id: Ice716cc4880dd17dc05bffcdce1dc1e4745108ea
Reviewed-on: https://pdfium-review.googlesource.com/27412
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
This Cl moves the code to create literals in the AST from
ParsePrimaryExpression to ParseLiteral.
Change-Id: I41ba20f28f1cb1d76d753c5baec790872acdf1da
Reviewed-on: https://pdfium-review.googlesource.com/27411
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
This CL removes the code from PrimaryExpression which converts the if
token into an indentifier. if() is a reserved keyword and can't be used
as an indentifier according to the spec.
Change-Id: I5644cdbe57ef62f4089b4704e1b8d196927e68a4
Reviewed-on: https://pdfium-review.googlesource.com/27370
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
|
|
The assignment operator can not be chained. This Cl removes the while
loop for assignments and changes it to an if(). We also can not have an
assignment inside ()'s so remove that option.
Bug: chromium:779349
Change-Id: I6934e18815f843ae8241023df6c03d8bbcd8168d
Reviewed-on: https://pdfium-review.googlesource.com/27350
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
|
|
Duplicate checks, remove.
Change-Id: Ic2f49651c50ed66328233817bc8cd24f7c9636c2
Reviewed-on: https://pdfium-review.googlesource.com/27330
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
Currently the parser builds assignment statements as part of the
SimpleExpression declaration. This isn't correct according to the
grammar where AssignmentExpression and SimpleExpression are siblings.
This CL moves the assignment calculation into the ExpExpression
declaration to make it a sibling of the SimpleExpression.
Change-Id: I6afac2379ab6783b84ee619863c8308ca0db454d
Reviewed-on: https://pdfium-review.googlesource.com/27310
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
This CL cleans up the FormCalc inheritance. The binary and unary items
all share ToJavaScript methods now.
Change-Id: I7bf0978449395fa2eb90b954cf2118d7aa3f71c6
Reviewed-on: https://pdfium-review.googlesource.com/27290
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
This CL removes the Loop base class as it adds no functionality. Other
base classes have had their ToJavaScript methods set as pure virtual and
their constructors made protected.
Change-Id: I5c77b8734d23c576dd52db7f72396ecdf2f7bd22
Reviewed-on: https://pdfium-review.googlesource.com/27270
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
This CL cleans up some of the JS generation code to make it easier to
see what JavaScript is begin created.
Change-Id: I4265226cca0e4de400d05cc0fea3f8c76608115e
Reviewed-on: https://pdfium-review.googlesource.com/27250
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
This CL inlines the FormCalc method names instead of using a lookup
array. Many of the names were only referenced once and this makes the
code a lot simpler to read.
Change-Id: Ib80f5bfa0097e4f1bad232e7de452f067db2a758
Reviewed-on: https://pdfium-review.googlesource.com/27211
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
This CL inlines the RUNTIMEFUNCTIONRETURNVALUE and
EXCLAMATION_IN_IDENTIFIER defines to make the output code easier to
read.
Change-Id: I4a86da2aefc75ff137d9a7cff0351515b275f1b1
Reviewed-on: https://pdfium-review.googlesource.com/27230
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
This CL merges the ToJavaScript and the ToImpliedJS methods in the
FormCalc expressions. The type of return is passed as a paramter to
ToJavaScript.
Change-Id: Idff83677bc70b964d95aa6ff6b0e2c1bf8c603ea
Reviewed-on: https://pdfium-review.googlesource.com/27210
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
This CL converts the CXFA_FMToken usages into an object instead of a
pointer. A copy constructor has been added. The line number was removed
from the token and is retrieved from the lexer where needed.
Change-Id: I94c632653e9bf1439d2ddf374a816ae0d10b5b67
Reviewed-on: https://pdfium-review.googlesource.com/27192
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
|
|
The keyword list in the formcalc lexer is only used to match
identifiers. We don't need to store the non-identifier tokens in the
list, so they're removed. The hash is removed and the list is compared
by string instead.
The token names have been moved to DEBUG so they won't be included in
Release builds.
Change-Id: Ieec00e9944960e559079083a605e3249c4128841
Reviewed-on: https://pdfium-review.googlesource.com/27190
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
|
|
Currently it's possible to create a formcalc script which creates a
large number of expressions. This will eventually cause stack exhaustion
as we try to allocate the needed expression objects.
This CL limits the number of parsed expressions in the PostExpression
section in order to keep from failing due to stack overflow.
Bug: chromium:799721
Change-Id: I69fca35db7f75ef97aec21c22fc06d926dfe2df6
Reviewed-on: https://pdfium-review.googlesource.com/26870
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
|
|
This CL renames cxfa_scriptcontext to cfxjse_engine and
cxfa_fm2jscontext to cfxjse_formcalc_context.
From reading the code, the script context appears to handle the v8 setup
and object code. The formcalc context code is related to handling the JS
code generated from the transpiler.
I, think, these new names make the intended usage clearer. They also
move the code into fxjs/ to keep along side the rest of the JS code.
Change-Id: I50619fbe48ca1f553a44cf0e0cb0210be8e45e4f
Reviewed-on: https://pdfium-review.googlesource.com/17130
Commit-Queue: dsinclair <dsinclair@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
|
|
This CL makes the use of CXFA_IsTooBig consistent and universal across
all of the ToJavascript and related methods. Previously this method
was only applied in some calls. It is now being tested as a
precondition and postcondition on every call and as a post condition
for the entire translation process.
There are some size checks within methods that potentially generate
large amounts of JS that have been left in.
BUG=chromium:752920
Change-Id: I1a8bfe21e0a17c2e47592fc6017060243674f1bc
Reviewed-on: https://pdfium-review.googlesource.com/16812
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
|
|
Change-Id: I3be788e06790d8102fc3793a50a58c19f05f855d
Reviewed-on: https://pdfium-review.googlesource.com/16790
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Henrique Nakashima <hnakashima@chromium.org>
|
|
There exists a similar check for the parser, but it doesn't catch all
cases of excessive memory usage, since a single parse step can
generate multiple expressions that need to be converted or other cases
where the parse depth doesn't match the emission depth later.
Due to the expressions appearing in two different inheritence
hierachies the depth information needs to be stored outside of the
classes, thus the new depth class.
Another way to handle this would be to change the method calls to take
in a visitor object that tracks depth. This would require significant
reworking of some of the code, so I am going to file a bug about doing
that conversion as a cleanup.
BUG=chromium:752495
Change-Id: Ica7c9b60ecf1e17530ea88b7bfb01582c63043be
Reviewed-on: https://pdfium-review.googlesource.com/16752
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Henrique Nakashima <hnakashima@chromium.org>
|