On Wednesday, 17 July 2019 at 13:38:44 UTC, Eduard Staniloiu wrote:
> I want to give a heads-up to everyone for the following issue (this had me scratching my head for a couple of days unit I caught it):
>
> The current code doesn't take into account `enum BaseType`s, ex:

Update: now the code takes into account enum base types. The generated code uses the `typedef` trick to have things work.

On Wednesday, 17 July 2019 at 14:26:11 UTC, Iain Buclaw wrote:
> On Wed, 17 Jul 2019 at 15:50, Seb via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>> On Wednesday, 17 July 2019 at 13:35:35 UTC, Iain Buclaw wrote:
>> >
>> > But apart from the construction (and possible destruction) of all frontend types, there shouldn't be anything duplicated.
>> >
>> > Did you consider cross compiler generation?
>>
>> Motivations for doing it inside DMD instead of a separate library:
>>
>> - DMD frontend isn't stable (AST nodes are often changed)
>> - DMD frontend isn't SemVer-tagged (so you can only rely on
>> ~master)
>> - people expressed a lot of interest in this being integrated
>> directly
>> - easier bootstrapping (though not really a concern if we require
>> the generated headers to be checked into the dmd repository)
>
> It doesn't make bootstrapping easier, as you will be starting from a
> base where either:
> 1. There is no D compiler
> 2. The D compiler does not understand -HC
>
> Having a standalone application means you only need to worry about (1) in order to be able to generate headers to then build the D compiler.

Maybe I'm missing something, but wouldn't the bootstrapping stay the same?
You start from (1) - no D compiler, you bootstrap the D compiler, and then you get `-HC`, right?

With the tool approach, you're still at (1), you bootstrap the D compiler and then build the tool with the bootstrapped D compiler.

Am I missing something?

On Wednesday, 17 July 2019 at 14:28:34 UTC, Iain Buclaw wrote:
> On Wed, 17 Jul 2019 at 15:40, Eduard Staniloiu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>>
>> I have the following question: Can we use C++11 or would that break GDC / LDC? With C++11 we could use `enum class` which would solve this nicely. The issue with `enum class` is that it will break code since not the fields need to be prefixed with the enum name.
>>
>> But still, what do you think? What are the pros and cons of supporting/using C++11?
>>
>
> No you cannot use C++11, yes it will break GDC bootstrap.

Can you elaborate a bit on this, please? I'm curious what are the reasons why we cannot use it.

Not really pushing for C++11, but I'd like to understand what is/ which are the blocker/s.

Thank you

On Wed, Jul 17, 2019 at 4:10 AM Eduard Staniloiu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Tuesday, 16 July 2019 at 13:46:56 UTC, rikki cattermole wrote:
> > So currently there is no way to restrict it to just extern(C)? I ask this because -HC makes me think C not C++ headers.
>
> Currently the outputted headers are C++ headers, but we were thinking of wrapping `extern (C++)` definitions inside an `#ifdef __cplusplus` block, and prefixing any `extern (C)` definitions with the following `EXTERNC` macro
>
> ```
> #ifdef __cplusplus
> #define EXTERNC extern(C)
> #else
> #define EXTERNC
> #endif
> ```
>
> This way, the generated header could be used in both C and C++.
>
> What do you think?

Sure, that sort of thing is normal and sensible.

On Wed, Jul 17, 2019 at 5:55 AM Eduard Staniloiu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Wednesday, 17 July 2019 at 11:52:17 UTC, Nicholas Wilson wrote:
> > On Wednesday, 17 July 2019 at 11:05:21 UTC, Eduard Staniloiu wrote:
> >> On Tuesday, 16 July 2019 at 13:46:56 UTC, rikki cattermole wrote:
> >>> So currently there is no way to restrict it to just extern(C)? I ask this because -HC makes me think C not C++ headers.
> >>
> >> Currently the outputted headers are C++ headers, but we were thinking of wrapping `extern (C++)` definitions inside an `#ifdef __cplusplus` block, and prefixing any `extern (C)` definitions with the following `EXTERNC` macro
> >>
> >> ```
> >> #ifdef __cplusplus
> >> #define EXTERNC extern(C)
> >> #else
> >> #define EXTERNC
> >> #endif
> >> ```
> >>
> >> This way, the generated header could be used in both C and C++.
> >>
> >> What do you think?
> >
> > It should be pretty trivial to just check the linkage of the symbols and only output extern(C) symbols.
>
> This would require two compiler switches, one for C (-HC ?) and
> one for C++ (-HCPP ?).
> Was trying to keep it as one compiler switch.

No, just emit one header with all the normal guards for C compilers.

#ifdef __cplusplus
# define EXTERN_C extern "C"
#else
# define EXTERN_C
#endif

// C declarations
EXTERN_C void cfunc();
EXTERN_C void cfunc2();
...

// C++ declarations:
#ifdef __cplusplus
void cppFunc();
...
#endif


If you detect that there are no C++ symbols at all, then you could simplify to:

#ifdef __cplusplus
extern "C" {
#endif

// C declarations
void cFunc();
...

#ifdef __cplusplus
}
#endif

On Wed, Jul 17, 2019 at 4:40 AM Eduard Staniloiu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> enum TestEnum
> {
>      TESTENUMaa = 0,
>      TESTENUMbb = 1
> };

What in earth is that?

On Wed, Jul 17, 2019 at 6:40 AM Eduard Staniloiu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> I want to give a heads-up to everyone for the following issue (this had me scratching my head for a couple of days unit I caught it):
>
> The current code doesn't take into account `enum BaseType`s, ex:
> ```
> enum TOK : ubyte { /* ... */ }
>
> class Expression
> {
>    TOK op;
>    /* ... */
> }
> ```
>
> The `enum TOK` above gets generated as
> ```
> enum TOK { /* ... */ }
> ```

So... use:

enum class TOK : unsigned char { /* */ };

??

On Wed, Jul 17, 2019 at 7:29 AM Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Wed, 17 Jul 2019 at 15:40, Eduard Staniloiu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >
> >
> > I have the following question: Can we use C++11 or would that break GDC / LDC? With C++11 we could use `enum class` which would solve this nicely. The issue with `enum class` is that it will break code since not the fields need to be prefixed with the enum name.
> >
> > But still, what do you think? What are the pros and cons of supporting/using C++11?
> >
>
> No you cannot use C++11, yes it will break GDC bootstrap.

This needs to be optional. I can't NOT use C++11 for instance... We could read the --extern-std flag to drive the output perhaps?

On Wednesday, 17 July 2019 at 13:38:44 UTC, Eduard Staniloiu wrote:
> I have the following question: Can we use C++11 or would that break GDC / LDC?

LDC has been requiring C+11 to build for a long time now. —David

On Wednesday, 17 July 2019 at 17:41:23 UTC, Manu wrote:
> On Wed, Jul 17, 2019 at 4:40 AM Eduard Staniloiu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>> enum TestEnum
>> {
>>      TESTENUMaa = 0,
>>      TESTENUMbb = 1
>> };
>
> What in earth is that?

This is the convention that is used in the manually written headers in order to avoid name clashing between fields of different enums in the C headers