Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Cannot read property 'generated' of undefined #2588

Closed
jussiry opened this Issue · 11 comments

5 participants

@jussiry

I have this weird bug that appeared once I updated Meteor to the newest version (0.5.0). I have the same version of CoffeeScript (1.3.3) both globally and in Meteor, but for some reason this bug only appears in Meteor. In any case, the error stack trace is all CoffeeScript, so i thought i'd start the search for solution here.

This bug appears when compiling CS that has any complex expression inside function, e.g.

foo(bar)

compiles well, but

foo(bar+1)

throws this error. Similarly foo(bar baz) throws the same error. Any idea what could be happening here? Here's the whole stack trace:

TypeError: Cannot read property 'generated' of undefined
  at Call.exports.Call.Call.filterImplicitObjects (/usr/local/meteor/lib/node_modules/coffee-script/lib/coffee-script/nodes.js:884:92)
  at Call.exports.Call.Call.compileNode (/usr/local/meteor/lib/node_modules/coffee-script/lib/coffee-script/nodes.js:914:19)
  at Call.exports.Base.Base.compile (/usr/local/meteor/lib/node_modules/coffee-script/lib/coffee-script/nodes.js:46:21)
  at Assign.exports.Assign.Assign.compileNode (/usr/local/meteor/lib/node_modules/coffee-script/lib/coffee-script/nodes.js:1554:24)
  at Assign.exports.Base.Base.compile (/usr/local/meteor/lib/node_modules/coffee-script/lib/coffee-script/nodes.js:46:21)
  at Return.exports.Return.Return.compileNode (/usr/local/meteor/lib/node_modules/coffee-script/lib/coffee-script/nodes.js:578:79)
  at Return.exports.Base.Base.compile (/usr/local/meteor/lib/node_modules/coffee-script/lib/coffee-script/nodes.js:46:21)
  at Return.exports.Return.Return.compile (/usr/local/meteor/lib/node_modules/coffee-script/lib/coffee-script/nodes.js:573:41)
  at Block.exports.Block.Block.compileNode (/usr/local/meteor/lib/node_modules/coffee-script/lib/coffee-script/nodes.js:307:23)
  at Block.exports.Block.Block.compileWithDeclarations (/usr/local/meteor/lib/node_modules/coffee-script/lib/coffee-script/nodes.js:391:19)
@michaelficarra
Collaborator

The stack trace shows nodes.js:884 as the source of the issue, but I cannot reproduce it. I very highly doubt this is us, since it works for you in the version of CoffeeScript installed normally. I say you take this up with them.

@jussiry

Thanks, here's the line that produces the error (node.js:884):

if (!((typeof node.isObject === "function" ? node.isObject() : void 0) && node.base.generated)) {

and here's the contents of node just before the error:

node { params: [], body: { expressions: [ [Object] ] }, bound: false }

Clearly the node doesn't have base and thus throws the error. I'm bit confused as to how Meteor can cause this error, since, as far as i know, it shouldn't modify coffee-script module in any way, but i'll open up an issue on their side too to see where this rabbit hole leads us.

@jussiry

Turns out this was a conflict between node.isObject and isObject function from Sugar.js: http://sugarjs.com/api/Object/isType

Currently CoffeeScript compiler tests if isObject function is defined or not, but since Sugar.js defines isObject for all objects, this causes an error. CS compiler should probably always define isObject, even as null, to avoid errors like this?

@jashkenas
Owner

Not really -- this is more of a lesson as to why you absolutely never extend native objects.

@jussiry

True, if you want to support older browsers. But with new functionality, such as Object.defineProperty this is not anymore the no no it used to be. Assuming all the libraries you use take this possibility into account.

@jashkenas
Owner

Actually, this ticket demonstrates exactly why it's still a "no no". CoffeeScript (or any other library) should not have to adjust code to accomodate particular functions being added to Object.prototype.

@jashkenas jashkenas closed this
@michaelficarra
Collaborator

@jashkenas: Sure, but you could argue that the compiler shouldn't be so sensitive to changes to the prototype. It's not like they're replacing Object::hasOwnProperty, where one would just expect that to break others' code. IMO, both parties are somewhat at fault.

@bitmage

I know it's not the fault of coffeescript, but is it possible to change the name of the function? This is going to cause a lot of people to waste their time, and doesn't seem hard to fix.

@bitmage bitmage referenced this issue in andrewplummer/Sugar
Closed

Conflict With Coffeescript #248

@andrewplummer

Chiming in mostly too late here but this bug is due to a feature of Sugar.js that does extend Object.prototype, however it's not intended for general use and is largely undocumented for that reason. Where it is documented it says "make sure you know what you're doing here" and the implication relevant here should be "if this breaks stuff, don't go complaining to them". If necessary I will work to make that more clear.

In normal use Sugar will never extend Object.prototype. As probably my only point of interaction with @jashkenas here, I want to make that as clear as possible :)

@bitmage

That's fair enough. I read the warning and decided to enable it, so I suppose I can deal with the results. :-)

Is there a clean way for me to define an exception to what properties get extended? I looked through the code a bit, but I guess I'm not finding the right place to do that without impacting sugar's regular functions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.