On Monday, 10 May 2021 at 09:27:35 UTC, Walter Bright wrote:

> Since this is all front end work, and it translates the C code into D AST nodes, it should "just work".

With that crucial information added it suddenly made perfect sense to me.

Brilliant!

> After all, CTFE "just worked" with ImportC. I didn't do a thing to enable it. I didn't do a thing to the glue code, optimizer, or back end (other than not generating moduleinfo).

How are modules defined? I mean, how do you import and symbol-reference it from D?

Assuming everything `extern` in C needs to be in the same module/namespace?

_Mark

On 5/15/2021 1:28 AM, Markk wrote:
> How are modules defined? I mean, how do you import and symbol-reference it from D?

The module name is generated from the file name, and all the C symbols go into it.

On Saturday, 15 May 2021 at 03:59:58 UTC, Walter Bright wrote:
> On 5/14/2021 6:11 PM, Dibyendu Majumdar wrote:
>> One suggestion I have is to add a test suite for the C compiler so that it is clear how conforming it is to Std C. A bunch of tests can be found at:
>> 
>> https://github.com/vnmakarov/mir/tree/master/c-tests
>
> Thank you. Those look good.

Other good tests:

Single file SQLite - https://www.sqlite.org/download.html

Single file Lua - https://github.com/lua/lua/blob/master/onelua.c

You could then run SQLite tests and Lua tests. if they pass that would be super amazing!

On Friday, 14 May 2021 at 05:27:27 UTC, Walter Bright wrote:
> As for the user having options, that's why we have multiple D compilers. ImportC isn't part of the D language, and so differing flavors of C support is within reason.

I hope this not lead to a fragmentation. Current we already have this case where if you want a faster compiling use DMD, but for production/optimization/reliability  go with GDC or LDC.

Matheus.

On 5/15/21 4:34 AM, Markk wrote:
> On Monday, 10 May 2021 at 09:27:35 UTC, Walter Bright wrote:
> 
>> Since this is all front end work, and it translates the C code into D AST nodes, it should "just work".
> 
> With that crucial information added it suddenly made perfect sense to me.
> 
> Brilliant!

ImportC is one of the coolest hacks I've seen in many years.

To think it took only 4 KLOC. I can't find my behind with a map in 4 KLOC.

On Saturday, 15 May 2021 at 16:03:01 UTC, Andrei Alexandrescu wrote:
> On 5/15/21 4:34 AM, Markk wrote:
>> On Monday, 10 May 2021 at 09:27:35 UTC, Walter Bright wrote:
>> 
>>> Since this is all front end work, and it translates the C code into D AST nodes, it should "just work".
>> 
>> With that crucial information added it suddenly made perfect sense to me.
>> 
>> Brilliant!
>
> ImportC is one of the coolest hacks I've seen in many years.
>
> To think it took only 4 KLOC. I can't find my behind with a map in 4 KLOC.

wrt to it being 4KLOC, I'm reserving judgement until it can compile something useful. The dmd AST is already a bit of a mess, making it compile two languages (i.e. more bitflags everywhere!) could make 4KLOC in the parser trickle down elsewhere all over the place (e.g. Struct forward decls, initializer lists etc. all have to find a home somewhere in the AST).

One thing of note here is that if it can compile a given C file, the compiler doesn't do a terrible job of representing it's AST as a string so this could also be utilized as a C to D converter.

On 16/05/2021 4:09 AM, Max Haughton wrote:
> wrt to it being 4KLOC, I'm reserving judgement until it can compile something useful.

Once it can compile zlib and successfully pass its test suite, then its something to be excited about!

On 5/15/2021 3:38 AM, Dibyendu Majumdar wrote:
> Other good tests:
> 
> Single file SQLite - https://www.sqlite.org/download.html
> 
> Single file Lua - https://github.com/lua/lua/blob/master/onelua.c
> 
> You could then run SQLite tests and Lua tests. if they pass that would be super amazing!

It sure would be amazing!

On a practical note, I've found that using various 3rd party projects as a test suite tends to be more work than they're worth, because:

1. No matter how big a project is, it tends to use only a subset of the language, and once one or two of its files compile, the rest will. This makes for a lot of costly busywork (test suite time). Compiling lots of code does not necessarily translate into good test coverage, it's the same constructs tested over and over and over again.

2. To know if the project compiles properly, then you've got to run the project's test suite. This can send one rather far afield.

3. Debugging a failure in the project means understanding that project - an expensive undertaking.

4. The 3rd party project then needs to be maintained along with the compiler.

The D test suite, on the other hand, is a large number of independent, minimized examples. When they fail, they're readily debuggable. They can be quickly processed. The redundancy is minimal.

So, I propose that once ImportC is ready, that persons familiar with those code bases try out the SQLite and Lua projects. Failures should be reduced to minimal test cases for incorporation into the ImportC test suite.

On 5/15/2021 6:35 AM, matheus wrote:
> I hope this not lead to a fragmentation. Current we already have this case where if you want a faster compiling use DMD, but for production/optimization/reliability  go with GDC or LDC.

Iain Buclaw, gdc's maintainer, is helping out with ImportC. Your concerns are in good hands!