Include guards missing - can't import same bundle twice in a dependency tree

[Bearmarshal]

There seem to be no include guards in any of the generated C files, leading to problems with a nestled dependency tree, such as the following:

  Foo
  / \
Bar Frob
  \ /
  Main

The error is trivial to trigger, just import the same bunde twice in a file:

bundle Foo where

passive class Foo {}

import Foo
import Foo

class Main {
  def main() : void {
    print(42);
  }
}

This also causes a circular dependency to throw the compiler into an infinite loop:

bundle InfiniteImport where
import InfiniteImport

class Main {
  def main() : void {
    print(42);
  }
}

[supercooldave]

I do mean to address this as a part of the module system, but development is (too) slow.
If you can think of a quick hack to deal with this, we'd be happy to #linclude it.

[Bearmarshal]

Would inserting #pragma once into each generated .h file work?

[supercooldave]

Perhaps .. maybe you could try on the generated C.
This would be an easy fix – I'm sure one of us could quickly implement it.

[Bearmarshal]

The duplication is caught during typechecking, though, so you would have to turn that off before getting any generated C...

[supercooldave]

Argh!

[EliasC]

@Bearmarshal: I'm pretty sure there is only ever a single .h file generated, even when including modules.

[Bearmarshal]

You are right. I guess that makes stuff less trivial then...

Perhaps surrounding all declarations made by a single bundle with

#ifndef BUNDLE_BundleName
#define BUNDLE_BundleName
...
#endif

I assume this would require some additional work, though, like keeping a separate list of declarations per bundle keyword, or so...

[Bearmarshal]

What are the arguments for not using multiple .h files?

[EliasC]

One way forward could be to check for duplicate classes when merging the class tables of different modules, and if they are from the same file, only keep one of them (and in the other case, rightfully give an error message and wait for @supercooldave's module system to provide namespaces). This information should be available in the SourcePos meta-information of the AST nodes.

[EliasC]

@Bearmarshal: As far as I can see, your problem is not at the C-level (yet) but rather on the Encore level. The simplest solution would be one that only required changes to one of them.

[Bearmarshal]

I've actually promised myself to not dig into the compiler source code (I would probably disappear from the face of Earth for a month if I did), so I'll wait.

[EliasC]

@Bearmarshal: But you want to get rid of the "Duplicate definition of ..." from encorec, right? You are not getting clang errors?

[Bearmarshal]

Yes, I want. And no, I'm not.