Hi Mike -
Thanks very much for your help! module->block->insertAtHead(result) seems to get the job done. I'm doing more testing now, but expect a pull request from me soon fixing this and maybe another LLVM problem. (We really need to get nightly/weekly LLVM testing going somehow...) Best, -michael On 08/07/2014 12:26 PM, Mike Noakes wrote: > > On Aug 7, 2014, at 8:41 AM, Michael Ferguson <[email protected]> wrote: > >> Hi - >> >> I've noticed that >> chpl --print-passes test/extern/ferguson/externblock/define.chpl >> now core dumps in the compiler because >> the extern block support tries to do >> module->initFn->insertAtHead(result); >> when trying to add a global variable, >> but module->initFn is NULL. >> >> This used to work but I recall seeing some recent >> changes to module initialization. >> >> Since readExternC runs fairly early on >> (so that it can happen before scopeResolve), >> it sometimes changes the AST in odd ways. >> How should it add a global variable? >> (Is there a way to request that the module's >> init function be created, for example? Or >> should it be doing something else?) >> >> Thanks, >> >> -michael > > > Hi Michael, > > I did the work to relocate the code that inserts Module Init functions from > Parse > to Normalize. > > I was surprised to see that there is a test that fails but now I see that it > relies on LLVM. > Apparently we haven't done a run with LLVM since I completed that work. > > 1) I'd be happy to take on the work to apply the required changes to enable > the LLVM > build to work with this change. > > 2) Alternatively you might find it is not terribly hard. There is a fair > chance that you > will be able to replace "module->initFn->insertAtHead(result)" with > "module->block->insertAtHead(result)" > > > > By way of a little background: > > Historically the parser collected the statements in the source level code in > to the block > and then ran a final pass in which the AST for a "module init function" is > created and > the most of the original contents of the block were inserted in to the body > of that function > (there are a few exceptions). > > During Normalize, most of body of the init function was pulled back out to > the Module > level leaving only the code necessary to initialize the module-level > variables etc. > > The passes that ran between Parse and Normalize had to "be aware" that most > of the > module was buried inside inside the Module init function; as the function you > are considering > appears to do. > > > > If you are willing I'd like to propose that you take the first step at the > proposed change but > I will be very happy to take over if it is not a relatively simple change. > > With regards, > > Mike > > > > > > > >> >> ------------------------------------------------------------------------------ >> Infragistics Professional >> Build stunning WinForms apps today! >> Reboot your WinForms applications with our WinForms controls. >> Build a bridge from your legacy apps to the future. >> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk >> _______________________________________________ >> Chapel-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/chapel-developers > ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
