Cake – A C23 compiler frond end written from scratch in C (opens in new tab)

Tried this:

    #include <stdio.h>

    int main()
    {
       puts("hello world");
       return 0;
    }

Got:

    source:5:4: error: not found 'puts'

     5 |  puts("hello world");
   |

Caught a typo already :)

My goal with the transpiler is not only the transpiler, although my front end had to be created differently of an normal compiler and preserve more tokens that could be discarded during the compilation. This also can be useful for a tool that does refactoring.. like renaming variables etc.. so in any case it it useful.

The new C23 language has a lot of features that makes your code not compile in previous C versions like attributes digit separators etc.. Someone may wants to create a new project in C23 and soon regret because the users of the code may need C99. This would be one use case, you can create a C23 code and have C99 versions of the same base code.

Unfortunately my transpiler is not "production ready" yet and I don't have IDE plugins etc.. that is required to make the tool more productive.

The other advantage, if we had a production ready transpiler with a IDE support etc.. it that we could use C23 and compile to C99 without having to wait for compilers like msvc to implements the standards.

Also some experimental features (like defer) can be used and you can distribute your code in standard C99. We have more freedom to use wherever we want and distribute a "readable" C99 code.

By the way most of the C transpilers or compilers generates C code only for immediate compilation. CFront was like that.

My transpiler have two modes one is for direct compilation and other is to distribute generated code.

Each mode has advantages and disadvantages.

> Why do I want a transpiler to take C23 code and convert it down to C99 code?

Because you are required to use Visual Studio or some compiler that barely even does C99/C11.

> If I was interested in using the C23 features, wouldn't I use a C23-ready compiler?

Yes, but maybe you can't guarantee a C23-capable compiler on all the platforms you care about, or maybe you are required to support VS/VC.

> That said... I do wonder how long it will be until ARM and GCC have a C23 toolchain - or did I just answer my own question?

You did :)

Transpiling is just a very useful idea. Sure, why even bother, the world should be perfect already! But the world isn't. And anyways, transpiling is a very cool idea. If you have time and funding (e.g., maybe you're a graduate student), then you might build it. If you don't have the time and funding you might wonder why even bother, except maybe you have the need and then you get the funding? Even if you don't have the time or funding, you might make an idea you care about into a hobby. So there's many reasons why one might want to build a transpiler.

In another thread we were talking about transpilers for SQL. There the motivation is much stronger and clearer than here, but it's of the same sort: portability. In the case of SQL there's so much variation across RDBMSes that if you must support more than one, you'll quickly wish you had a transpiler for some dialect, or even for an alternative query language.

Another thing is that a transpiler won't need to do much analysis or optimization, so it can be fairly simple compared to a full compiler, but! a transpiler can be much less ambitious than -and a great starting point for- constructing a compiler.

Targeting a compiler with poor language support?

Or Cake by the Ocean Blue. https://www.youtube.com/watch?v=K9VfJqHwYKs

I suspect this project is not quite as cool as sex on the beach.

Even having experience with C/C++, C preprocessor and C declarations took a long time. Some time to get used to the grammar as well.

A language without preprocessor and a simple grammar saves a lot time and you can go direct for the funny parts.

The part that is the "transpiler" is visit.c and visit.h.

You can use it as reference to create different "visits". For instance, I am implementing a code format at "visitformat.c".

I have implemented a "naming convention checker" inside the parser, but it also can be a "visit".

Static analysis etc..can be a visit.

Inside the visit context you will find

struct ast ast;

That is the AST.

I would say the syntactic analysis parser is 100% complete C23.

Semantic analysis that is not 100%.

You can also use pycparser[0]. It is fully compatible C99, but be careful it doesn't support gnu extensions (like attributes, #indent, asm() ...). You can however work around most of them by -D defining them to empty macro in the argument.

[0] https://github.com/eliben/pycparser

Note that while support for anything post C89 used to be spotty at best, the Visual Studio situation has improved in recent years, see e.g. [1].

[1] https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-...

Everything that is not part of C23 I annotated with "extension". For instance "Extension Defer" or "Extension Lambda" are not part of C23.

It's a front end. The backend implemented generates C code. I hope to have other backends in the future.

It's all of them.

A transpiler is still a compiler. A front-end compiles to an intermediate state (C99 in this case).

It isn't CMake's job to do this. Just have it pass a flag to your compiler to use a custom pre-processor (--no-integrated-cpp -B<path>). Should work... hopefully. Might also have to pipe through the preprocessor again since OP's most likely won't be processing #includes and such

No lie.