http://d.puremagic.com/issues/show_bug.cgi?id=6461
--- Comment #12 from Martin Nowak <c...@dawg.eu> 2013-05-31 09:19:19 PDT --- (In reply to comment #11) > (In reply to comment #10) > > IIRC TypeInfo instances were the only symbols where s->getModule() returns > > NULL. > > I had the impression that the init-data has the same problem, but I could also > have been confused by other issues (the multiobj library creation doesn't work > at all for omf atm). > > > But a TypeInfo instance should belong to the module of the described Type. > > I hope that we can remove the hack if we fix that behavior and assert > > s->getModule. > > The problem also exists for derived types like const(Struct) or Struct* (maybe > also for basic types?). You cannot generate all possible types into the module > itself (and you might not have it compiled anyway if the declaration is only > in > a di file). E.g. for const(Struct) you'll have to at least generate the > TypeInfo_Const that refers to TypeInfo_Struct somewhere into the current > compiler output. True, but wouldn't it still make sense to emit these into a doppelg�nger module of the original module? One problem is, that this required linking against the original module, because it references assert etc. As this only seems to happen with data we don't actually need the module functions, so we could omit them. Also emitting them to a doppelg�nger of a special anonymous module would make more sense than to reuse the last filename. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
