I'm less sure about adding unittests to the C compiler. I decided to flirt with heresy and leave this in, because it sure makes adding tests convenient! Scroll down a bit and you'll see it executes C functions at compile time. You can see it in action in the test cases in this file: Is it really C if that is allowed? Already, the C code allows for Compile Time Function Execution, which comes for free by passing the C code through the D front end. But it turns out you can simply give the C file on the command line, and it'll compile it and make an executable:īut then there's the question "should D features be allowed in the C code?" This is a very subversive question. The point of ImportC is to import the declarations from a C file. I'll be watching the evolution of this new feature in D with great interest! Maybe someday the Zig distribution that does not have LLVM extensions enabled will be the more popular one. Still, I think your maneuver here is the best long-term approach to tackle this problem, and I imagine as time goes on we'll start to migrate towards D's solution here. For example, LLVM itself is C++ so if Zig wants to be able to bootstrap itself, it needs this capability. Sadly this ability is just too useful in practice to ignore. On Zig's end of things, all we have to do is provide libcxx, libcxxabi, libunwind, compiler-rt, and linking, and then libclang is really pulling a lot of weight by compiling C++ code into object files. One thing that might make libclang worth the cost, however, is its ability to compile C++ code as well. Ironically, Vexu started from the other side as you, with the preprocessor mostly done, but the backend left to-do: We might follow your lead on this, as we have done with so many other great ideas implemented in D. > libclang will exceed the cost of doing our own C compiler. > I wouldn't be surprised that the eventual cost of adapting ourselves to Without a C compiler, we're stuck with, wedded to, and beholden to libclang. Makefile:44: recipe for target 'warp.o' failed Possibly caused by forgetting to " ~ "complete a git merge in your code." Ranges.d(71): Use the explicit syntax instead (concatenating literals is "Buffer overflowed. Ranges.d(71): Error: Implicit string concatenation is error-prone and disallowed in D Macros.d(338): Error: Built-in hex string literals are obsolete, use !"FD 61 62 FD FD" instead.
Macros.d(333): Error: Built-in hex string literals are obsolete, use !"FD" instead. Macros.d(329): Error: Built-in hex string literals are obsolete, use !"FD 61 FD" instead. I wouldn't be surprised that the eventual cost of adapting ourselves to libclang will exceed the cost of doing our own C compiler.īut dlang has a long problem of change constantly without backward compatibility and a lot of projects just die because of it, for example the mentioned :ĭmd -c -O -inline -release -ofwarp.o cmdline.d constexpr.d context.d directive.d expanded.d file.d id.d lexer.d loc.d macros.d main.d number.d outdeps.d ranges.d skip.d sources.d stringlit.d textbuf.d charclass.dĬontext.d(222): Error: Implicit string concatenation is error-prone and disallowed in DĬontext.d(222): Use the explicit syntax instead (concatenating literals is "# 1 \"%2$s//\"\x0a" ~ "# 1 \"\"\x0a"Ĭontext.d(223): Error: Implicit string concatenation is error-prone and disallowed in DĬontext.d(223): Use the explicit syntax instead (concatenating literals is "# 1 \"\"\x0a" ~ "# 1 \"%1$s\"\x0a" Without a C compiler, we're stuck with, wedded to, and beholden to libclang. We only need to implement currently used ones (not the 16 bit stuff), and only the stuff that appears in C headers. There are a lot of wacky C extensions out there. The D code will be able to inline C code, and even CTFE it.
Fortunately, I already did that and we can use it if we choose. Writing a C preprocessor is a nightmare. Semi-related project, using libclang to import C++ directly (with C++ templates and all the other features, regular D has C++ linking and exception support built-in): He implemented the ANSI C compiler here in just 5 days. This pull request actually implements its own C compiler! For Walter, considering he's implemented C++98 alone, implementing C must be nothing :) Context: Walter Bright created the first native C++ compiler, Zortech C++.
0 kommentar(er)
