
Hacking on Clang is surprisingly easy - mort96
https://mort.coffee/home/clang-compiler-hacking/
======
atq2119
The article mentions debug build time as a legitimate pain point about the
LLVM project. General good advice, which unfortunately isn't enabled by
default: use dynamic linking, make sure you're using lld, enable split dwarfs
(and -Wl,--gdb-index for faster gdb load times!), enable optimized
tablegen[0]. ccache doesn't hurt but isn't actually such a big benefit unless
you switch between branches a lot.

Oh, and buy a Threadripper. Seriously, you won't regret it.

[0] TableGen is LLVM's internal DSL swiss army knife. You can separately
enable optimizations for TableGen independently of optimizations in the
resulting LLVM builds, which you should basically always do unless you're
working on TableGen itself.

~~~
chrisseaton
Do you know why isn't it easier to offload compilation to the cloud yet?
Compilation is an embarrassingly parallel problem and shouldn't need take
longer than than slowest file plus linking. Compilation is also a pure
function (I know it's not quite set up like that in practice but it is in
theory) so it's stateless and cacheable. I would have thought developers could
share a massive cluster and have thousand-way compilation instantly. Doesn't
seem to be a thing people are building or using in practice for some reason.

~~~
saurik
I nearly have this working, using AWS Lambda (a few months ago I got super
angry at the compile times for a project I was working on and spent a week
getting a proof of concept ready that I have been refining since). Have sadly
been busy with some other tasks I have to get done (age old story), but intend
to push to the point where you could easily add it to your own project soon
(as long as your build system isn't stupid; a lot of people think they are
using super advanced build systems, but in practice they handle toolchain
hacks extremely poorly :/).

~~~
chrisseaton
If I was writing a new compiler from scratch today I think I'd make it client-
server from the start, even locally, so that the compiler could be
transparently made remote. The client would be responsible for doing all IO on
behalf of the server so that the server was completely separated from the
system it ran on.

------
pythux
Really cool read. One thing which I was curious about, but is not completely
related to the article, is how the workflow of making changes to a big project
like Clang looks like. Is there some « watch » mode to iterate faster without
needing to rebuild? What kind of tooling/editor is recommended, is there some
linting support? Is it possible to quickly identify a subset of tests to run
for the changes made? (In this case I assume there are tests for lambda
parsing?).

~~~
mort96
My workflow was extremely simple; a terminal window, with cutting-edge tools
like ripgrep to search for patterns and neovim to edit. When I had made a
change, I ran make.

When I wanted to test out a change, I had print statements in the clang source
code and wrote a small test file which I could use to decide whether the
prints I saw matched the prints I expected to see. Revolutionary stuff, I
know. One trick I like when working with huge projects is to do my printf
debugging with `fprintf(stderr, ...)` instead of the project's standard
logging, just to avoid having to fight with log levels and such. (These print
statements should obviously be removed once they're no longer necessary; here
again, using fprintf helps, because they stand out.)

I didn't even think about tests, but I'm happy to report now that the entire
test suite still works after my change. I don't think any kind of test-driven
debugging would have worked here; almost none of the challenge was in the
actual code behind the feature, it was all mostly just work to try to
understand the code base. For example, "Oh, this looks like it's where lambdas
are parsed. Let me add a print here and try to compile a file with a lambda to
see if I'm right", or "Ok, I think I should end up in this branch if I have a
fat arrow token in a lambda expression, let's add a print statement and modify
the test file to check if that's true".

------
s_gourichon
The simplified syntax looks pretty much like the C# syntax.

[https://docs.microsoft.com/en-us/dotnet/csharp/language-
refe...](https://docs.microsoft.com/en-us/dotnet/csharp/language-
reference/operators/lambda-operator)

------
FpUser

      [](auto &&a, auto &&b) { return a.id() < b.id(); };
    

I vary much prefer the version above than the one author proposes for
replacement. C++ is a beast as it is. No reason to introduce more miracles
there. My opinion of course

~~~
TheDong
I dunno, it's kinda consistent. Braces are optional for single expression
bodied if statements too. It doesn't really seem all that strange for them to
be optional for single expression lambdas.

------
zelly
You could also use libclang to parse and codegen the extra braces.

[https://clang.llvm.org/docs/Tooling.html](https://clang.llvm.org/docs/Tooling.html)

That way you don't have to maintain your own branch of clang.

------
RMPR
That's why I like hacker news so much, you can stumble upon an article
answering many questions you asked yourself since forever, great article!

