eval/backlog.txt

   1 The eventual goal is that eval should support the same language as ASC.  This
   2 backlog records all the things we know are not supported; keep it up to date
   3 and pick tasks off it.
   4
   5 Current status: We can run almost all of the ecma3/ and e4x/
   6 acceptance tests from source.
   7
   8 Work list is organized as P1/P2/P3/P4/P5 where P1 is highest and these mean:
   9
  10   - P1 - basic functionality
  11   - P2 - rough compatibility with ES3
  12   - P3 - rough compatibility with AS3 and E4X
  13   - P4 - quality requirements / subtle semantics
  14   - P5 - desirable extensions
  15
  16 Note that FIXMEs in the code are generally not noted here.
  17
  18
  19 Lexer:
  20
  21   (nothing)
  22
  23
  24 Parser:
  25
  26   P3:
  27   - 'config namespace'
  28   - program configuration scope, checking
  29   - program configuration attributes on blocks, expressions in array / object (but not vector) literals
  30   - program configuration attributes on definitions
  31   - 'package', 'class', and 'interface' are parsed but mainly superficially, see FIXMEs
  32   - 'public', 'private', 'protected', 'native', 'static', 'prototype', and named NS are parsed but not really used anywhere
  33   - lots of places that parse by 'identifier()' should parse by something that handles both id and id::id
  34   - generic types (ie, Vector)
  35   - 'super' both stmt and expr
  36   - getter and setter functions
  37
  38   P4:
  39   - operator-precedence parsing of expressions
  40   - non-recursive parsing of if-then-else chains
  41   - stack overflow control generally
  42
  43 Code generator:
  44
  45   P3:
  46   - qualified 'import' statement
  47   - 'const' statement and definition
  48   - 'use namespace' statement
  49   - 'namespace' definition, I deliberately broke these
  50   - (many more to come, as the parser handles more AS3 constructs)
  51
  52   P4:
  53   - Variable definitions must not override function definitions or param definitions
  54     in the same scope, as per E262-3.  Also there may be some fine points with
  55     exactly when 'arguments' is initialized.
  56   - non-recursive generation of if-then-else chains
  57   - stack overflow control generally
  58
  59
  60 ABC layer:
  61
  62   P3:
  63   - instance
  64   - class
  65
  66
  67 Code quality, utility, API, etc:
  68
  69   P4:
  70   - Transition to VMPI_ forms of libc functions everywhere.  I've converted the code
  71     but I need to provide macros in the standalone compiler setup as well.  Also note
  72     that the VMPI layer in Tamarin does not currently provide a mapping for vsnprintf,
  73     for example.
  74
  75   - Syntax error messages are more ad-hoc than they need be, probably.  See the
  76     string constants in eval-compile.cpp.
  77
  78   - Syntax error messages sometimes provides less information than they need to;
  79     the "wrong token" error is the worst but others are bad too.
  80
  81   - Eval code should not use unadorned 'new' for anything; instead the HostContext
  82     should have alloc() and free() methods for allocating memory.  These should be
  83     used with placement new or just by themselves as appropriate, and we should
  84     never use 'delete' for anything.  Nor should there be any use of malloc or
  85     calloc or similar.  The purpose of this rule is to not depend on the memory
  86     management provided by new or delete, as they sometimes are diverted to FixedMalloc
  87     and sometimes not (depending on platform), when eval is embedded in the avm.
  88
  89     Now, Tommy says that we should be moving toward a world where we assume that
  90     new and delete are overloaded and point to FixedMalloc, but there are some
  91     platforms where that is actually hard (toolchain issues).  So if there's not
  92     a lot of work to abstract it out - and there's no reason that it should be
  93     a lot of work because almost all allocation goes through the Allocator anyway -
  94     then we should probably do it.  (Would also let us know something about the
  95     memory consumption of eval.)
  96
  97   Optimizations:
  98   - Store local variables in registers if the function does not close over
  99     other functions and does not use 'with' (at least) - ESC implemented this,
 100     it yields significant performance improvements
 101
 102   - Reuse locals of the same type; right now we generate a lot of local slots
 103     in order not to annoy the verifier, but doing better would result in lower
 104     stack consumption
 105
 106   - Improved scope stack tracking.  Right now the code generator just sums the
 107     number of PUSHSCOPE and PUSHWITH instructions, which yields a conservative
 108     approximation to the actual depth.  Probably pretty close in practice,
 109     but in a function with a lot of exception handlers it may be a substantial
 110     overestimate because there will be PUSHSCOPE/PUSHWITH instructions to reconstruct
 111     the scope stack inside each handler.
 112
 113   - OP_dxns instead of OP_dxnslate when the argument is a string or the name
 114     of a namespace definition.
 115
 116   - namespace qualifiers should be inserted literally when they are known at
 117     compile time, not result in RTName code generation.
 118
 119   - namespace sets should probably be canonicalized (eg in lexicographic order)
 120     so that duplicates can be filtered easily, we want to filter duplicates
 121     both in the parser and when inheriting namespace sets in the code generator.
 122
 123 Test harness:
 124
 125   - need tests for eval function, too
 126
 127
 128 Documentation bugs:
 129
 130   - AS3 docs list 'to' as a keyword but test suite uses 'to' as an identifier.
 131
 132
 133 Bug triage (open bugs):
 134
 135   - These are the same problem:
 136
 137         ecma3/ExecutionContexts/e10_1_4_10.as : FAILED contained no testcase messages - reason: 10.1.4-10 Scope Chain and Identifier Resolution
 138          | TypeError: Error #1004: Method Number.prototype.toString was invoked on an incompatible object.
 139          | at Error$/throwError()
 140          | at <anonymous>()
 141          | at getTestCases()[ecma3/ExecutionContexts/e10_1_4_10.as:58]
 142          | at global$init()[ecma3/ExecutionContexts/e10_1_4_10.as:43]
 143         ecma3/Statements/e12_10.as : FAILED contained no testcase messages - reason:
 144          | TypeError: Error #1004: Method Number.prototype.valueOf was invoked on an incompatible object.
 145          | at Error$/throwError()
 146          | at <anonymous>()
 147          | at getTestCases()[ecma3/Statements/e12_10.as:53]
 148          | at global$init()[ecma3/Statements/e12_10.as:42]
 149
 150     The structure is "with (new Number(x)) toString()" - or valueOf.
 151
 152
 153 Tests in the 'ecma3' test suite that can't pass at this time:
 154
 155   - ecmas3/LexicalConventions/e7_1_1.as fails with a syntax error because
 156     a no-break space encoded in some strange way in a comment trips up the
 157     the UTF8 decoder in the string class.  Instead of detecting invalid
 158     UTF8 content and letting my code fall back on Latin-1 it decodes it
 159     but screws the decoding up, so final characters are missing and the parse
 160     fails.
 161
 162   - string-to-number conversion:
 163        ecma3/GlobalObject/e15_1_2_2_2.as
 164        ecma3/GlobalObject/e15_1_2_2_2.as
 165        ecma3/GlobalObject/e15_1_2_2_2.as
 166        ecma3/LexicalConventions/e7_7_3.as
 167        ecma3/LexicalConventions/e7_7_3.as
 168        ecma3/LexicalConventions/e7_7_3.as
 169        ecma3/LexicalConventions/e7_7_3.as
 170        ecma3/Number/e15_7_3_2_1.as
 171        ecma3/Number/e15_7_3_2_2.as
 172        ecma3/Number/e15_7_3_2_3.as
 173        ecma3/ObjectObjects/e15_2_1_1_rt.as
 174        ecma3/String/e15_5_4_7_2.as
 175        ecma3/TypeConversion/e9_3.as
 176        ecma3/TypeConversion/e9_9_1_rt.as
 177      The largest number the built-in parser will parse as a non-infinity is 1.7976931348623145e308.
 178      But the test cases assume that 1.7976931348623157e308 will be parsed as non-infinity, and
 179      the number parser in ASC does this.  Some test cases can be fixed by replacing the latter
 180      literal by Number.MAX_VALUE.
 181
 182   - Also see bugzilla 608474
 183
 184   - uses 'class':
 185      ecma3/Expressions/e11_2_2_1.as
 186      ecma3/Expressions/e11_2_4.as
 187      ecma3/Expressions/e11_4_3.as
 188      ecma3/Expressions/e11_9_4.as
 189      ecma3/Expressions/e11_9_5.as
 190      ecma3/Statements/e12_6_3_12.as
 191      ecma3/RegExp/eregress_122076.as
 192
 193   - uses 'import':
 194      ecma3/ObjectObjects/class_006.as ("import flash.system.Capabilities")
 195
 196   - uses 'use namespace':
 197      ecma3/String/e15_5_3_2_1.as
 198      ecma3/String/e15_5_4_6_2_rt.as
 199
 200   - probably incorrect test:
 201      ecma3/TypeConversion/e9_3_1_3_rt.as - wants \0 in a string to turn into a digit '0' but E262-3
 202        explicitly sanctions \0 as a valid escape sequence that turns into NUL
 203
 204
 205 Tests in the e4x test suite that fail for apparently no fault of eval:
 206
 207   - fail with the JIT but not with the interpreter:
 208
 209       shell.as e4x/shell.as e4x/Statements/e12_1.as : 2 =  FAILED! expected: <soap:Body xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
 210       shell.as e4x/shell.as e4x/Statements/e12_1.as : 3 = <Envelope soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><Body><stock:GetLastTradePrice xmlns:stock="http://mycompany.com/stocks"><stock:symbol>DIS</stock:symbol></stock:GetLastTradePrice></Body><soap:Body><stock:GetLastTradePrice xmlns:stock="http://mycompany.com/stocks"><stock:symbol>MYCO</stock:symbol></stock:GetLastTradePrice></soap:Body></Envelope> FAILED! expected: <soap:Envelope soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><stock:GetLastTradePrice xmlns:stock="http://mycompany.com/stocks"><stock:symbol>MYCO</stock:symbol></stock:GetLastTradePrice></soap:Body></soap:Envelope>
 211       shell.as e4x/shell.as e4x/Statements/e12_1.as : 6 =  FAILED! expected: http://schemas.xmlsoap.org/soap/envelope/
 212       shell.as e4x/shell.as e4x/Statements/e12_1.as : 7 =  FAILED! expected: http://schemas.xmlsoap.org/soap/envelope/
 213       shell.as e4x/shell.as e4x/Statements/e12_1.as : 9 =  FAILED! expected: http://schemas.xmlsoap.org/soap/envelope/
 214       shell.as e4x/shell.as e4x/Statements/e12_1.as : 14 =  FAILED! expected: bar
 215       shell.as e4x/shell.as e4x/Statements/e12_1.as : Namespaces in global scope:  = 0 FAILED! expected: 3
 216
 217     However the interpreter has other failures (it fails #7 outright), and it looks
 218     like the wrong code is generated for property references.  I translate a.x as
 219     a.public::x but E4X really wants a.*::x.  This seems like a dangerous fix in
 220     general unless * translates as "public" for the purposes of non-E4X objects,
 221     so who knows what's actually going on here.  It's possible that there's magic
 222     somewhere in Tamarin to handle * as * for E4X and as [public] for everyone
 223     else.