kolodny / es-lab Goto Github PK

15.1.2.1.1 in the ES5 spec does not make the determination of whether an 
eval is an operator or function dependent on the number of parameters 
passed to it.

Currently
   eval('foo')
is an EvalExpr, but
   eval('foo', 'bar')
is not.

Parsing:

/\b/
or /\/

makes the parser crash with a "this[rule] is undefined" Ometa error.

The program "for ((x in y) in z);" does not parse, because the parser
disallows "in" expressions in the first expression of a for-in loop.

While the first expression in a for-in loop should disallow 'in'
expressions at top-level, it should allow them in subexpressions nested
within that expression.

Parser does not catch all 'early errors' yet (cf. Section 16 of the ES5 spec)
Intent is to write a post-processing tree-walker that reports these.

Currently, 

    "use strict";

even in directive prologue position produces

    ["LiteralExpr",
      {
        "type":"string",
        "value":"use strict"
      }
    ]

Since this captures only the value of the string, and not the original text
of the literal, it isn't even possible to determine in a post-pass whether
this was a Use Strict Directive. (See ES5 section 14.1)

Instead, we should introduce a new kind of AST declaration node:

    ["PrologueDecl", { "directive":"use strict" }]

where the value of the directive attribute is a string whose contents are
the source code of the part of the directive prologue between the outer
quotes. For example, the above represents a valid Use Strict Directive.
However,

    "use\ strict"

would parse to

    ["PrologueDecl", { "directive":"use\\ strict" }]

which will be interpreted as an unrecognized directive prologue.

The ES5 Parser currently only properly supports the ASCII subset of Unicode.
Unicode escape sequences in strings are supported, however (e.g. "\u000a")

in line 82 of traits.js :
http://code.google.com/p/es-lab/source/browse/trunk/src/traits/traits.js#82

it seems the getPrototypeOf fallback implementation is wrong and should really 
be:

 return obj.prototype;

instead of 

 return Object.prototype;

Since I didn't try to use the lib yet, I don't know if this cause any problem 
though, but I bet it could.

Currently, the direct eval operator syntax

    eval(foo)

parses into

    ["CallExpr",
      {},
      ["IdExpr",
        {
          "name":"eval"
        }
      ],
      ["IdExpr",
        {
          "name":"foo"
        }
      ]
    ]

However, because the semantics of this form may be a direct eval operator,
which is very different from a CallExpr, it should have its own AST type, say

    ["EvalExpr",
      {},
      ["IdExpr",
        {
          "name":"foo"
        }
      ]
    ]

What steps will reproduce the problem?

I have a strange bug on google chrome.

var T1 = Trait({
    x: 1,
    y: 2
  });

  var T2 = Trait({
    z: 3
  });

  var obj = Trait.create(Object.prototype,
                         Trait.compose(T1,T2));
obj.x = 5;
obj.x; // => 1

It works fine on safari

What is the expected output? What do you see instead?

obj.x == 5


What version of the product are you using? On what operating system?

0.4

Please provide any additional information below.

Future reserved keywords for strict-mode not yet supported by the parser
(cf. ES5 spec Section 7.6.1.2).

Bug reported by Nathan on the traits.js mailing list:

var obj = Trait.create({ hello: "world" }, Trait({ toString:
function() { return this.hello; } }));
obj.toString(); // -> "world"

var obj = Trait.create({ hello: "world" }, Trait({
 hello: Trait.required,
 toString: function() { return this.hello; }
}));
obj.toString(); // -> this.hello is undefined

// tried on node v0.2.4
var Trait = require('traits').Trait;
var t = Trait({ get foo() { return 42; } });
var o = Trait.create(Object.prototype, t);

>TypeError: Invalid property.  A property cannot both have accessors and be 
writable or have a value: #<an Object>

In this patch:
* I define LeakyWeakMaps (implemented with a key/value arrays pair)
* I replace the 2 key/values array pairs (hidden record and leaky weakmap for 
non-extensible objects) by LeakyWeakMaps

A natural consequence for hidden records is that the API they expose is the one 
of a weak map. If an attacker comes to know HIDDEN_NAME, the authority she's 
granted (with an object 'o' having HIDDEN_NAME as property) is equivalent to 
having access to a weakmap which keys are weakmaps using o as key.
Consequently, unless an attacker knows already some weakmaps that use o as key, 
she cannot do anything useful. In case she does know some of thee weakmaps, she 
cannot do anything more than what she can do with the WeakMap.protoype API, so 
no additional authority is granted.

So, knowing HIDDEN_NAME does not provide more authority than not knowing it.

Try typing it into 
http://es-lab.googlecode.com/svn/trunk/site/esparser/index.html

See https://bugs.ecmascript.org/show_bug.cgi?id=8

a small correction

Bug : http://jsfiddle.net/jkegJ/2/

Related github issue : https://github.com/nrstott/traits.js/pull/1

It would appear that getter/setter's on Object.prototype are broken when using 

`map[name] = pd` 

at 

http://code.google.com/p/es-lab/source/browse/trunk/src/traits/traits.js#272

Replacing it with a `defineProperty` call on `map` makes the bug dissapear.

What steps will reproduce the problem?
1. Load the page
2. Open the source
3. There's no doctype before <HTML>

What is the expected output? What do you see instead?
<!doctype html>

What version of the product are you using? On what operating system?
Win7 x64

Please provide any additional information below.

This prevents the site from working properly in IE, which triggers IE5 mode.

On major browsers (tested on FF5, Chrome 11 and Opera 11.11), window.frames === 
window. This could be a way for a script writer to access the global object 
without having been invited to.
For instance, in:
-----
(function(){
  return ({}).toString.call(frames);
})();
-----
The "frames" identifier resolves into the global object.
Return value is "[Object Window]"

Mike Samuel noted:
>> the lack of a separate parse tree node for Catch blocks
>> complicates [scoping] analysis.  Catches introduce a scope which is separate
>> from the other children of TryCatchStmt and TryCatchFinallyStmt

A "try {} catch(e) {}" statement should be parsed as:
>
> ["TryStmt",
>     {},
>     ["BlockStmt",
>       {}
>     ],
>     [ "CatchClause"
>       ["IdPatt",
>         {
>           "name":"e"
>         }
>       ],
>       ["BlockStmt",
>         {}
>       ]
>     ]
>   ]

(the difference with the current version is the introduction of a nested
"CatchClause" AST)