There are two screw cases for javascript that I know of that have to do with 'implicit semicolon insertion' (an idea I thing Brendan regrets).
Screw case #1: return value becomes: return; <unreachable expression> And <whatever> (parenthesized expression) becomes: <must be a function call>(expression is treated as parameters) So, when the whole program is being unparsed, the unparser is careful to insert semicolons where there could be an ambiguity. I guess you are right, that if the last element of a translation unit could be incorrectly parsed with the first element of the next one, we need to insert an explicit semicolon. You could try just appending a semicolon to the output after each unit and see if that makes the problem go away. It should be innocuous, because a stand-alone semicolon is just an empty statement. On 2010-05-17, at 15:47, Henry Minsky wrote: > So, I guess previously the JavascriptGenerator would put semicolons after > each > statement it output, but not around the whole body of the program. Now that > we're > calling the unparser on just chunks of tree, do we need to explicitly put > semicolons > after each 'top level' translation unit that we output? > > > > On Mon, May 17, 2010 at 3:13 PM, Henry Minsky > <[email protected]>wrote: > >> Oh actually , there's a missing semicolon at the end of the Class.make() >> statement... hmm. >> >> < }],LzView,["tagname","foo","attributes",new >> LzInheritedHash(LzView.attributes)])(function(){ >> --- >>> }],LzView,["tagname","foo","attributes",new >> LzInheritedHash(LzView.attributes)]);(function(){ >> >> >> >> >> On Mon, May 17, 2010 at 3:05 PM, Henry Minsky >> <[email protected]>wrote: >> >>> The code I wrote in JavascriptGenerator which take the code in blocks from >>> the lzx compiler addScript() calls is inserting a newline between each chunk >>> it append to the output file. I wonder if that is causing this somehow. >>> >>> On Mon, May 17, 2010 at 2:53 PM, Henry Minsky >>> <[email protected]>wrote: >>> >>>> This is kind of strange. The javascript output from before and after that >>>> changeset is the same except for newlines. And the additional newlines seem >>>> to be causing the error >>>> >>>> >>>> >>>> >>>> >>>> On Mon, May 17, 2010 at 1:03 PM, Henry Minsky <[email protected] >>>>> wrote: >>>> >>>>> hmm, could be, I'm trying to get a minimal test case, then I can trace >>>>> and see if >>>>> that's not getting called or something. >>>>> >>>>> On Mon, May 17, 2010 at 12:38 PM, P T Withington <[email protected]> wrote: >>>>> >>>>>> On 2010-05-17, at 12:33, P T Withington wrote: >>>>>> >>>>>>> If I run >>>>>>> >>>>>>> >>>>>> test/style/metasuite.lzx?debug=true&url=foo&lzr=dhtml&lzbacktrace=true >>>>>>> >>>>>>> at tot, it halts in DHTML will a strange error: >>>>>> this.$lzsc$initialize is undefined >>>>>>> >>>>>>> If I revert back to r16359, all is well. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> I reopened LPP-8994. >>>>>> >>>>>> I note that translateClassDirectives in CommonGenerator transforms >>>>>> constructors into $lzsc$initialize. I know you had to do something funny >>>>>> about constructors in your recent remodularization, so I'm wondering if >>>>>> that >>>>>> transformation is getting skipped somehow? >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Henry Minsky >>>>> Software Architect >>>>> [email protected] >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Henry Minsky >>>> Software Architect >>>> [email protected] >>>> >>>> >>>> >>> >>> >>> -- >>> Henry Minsky >>> Software Architect >>> [email protected] >>> >>> >>> >> >> >> -- >> Henry Minsky >> Software Architect >> [email protected] >> >> >> > > > -- > Henry Minsky > Software Architect > [email protected]
