[LLVM 17.0.1 released! - Announcements - LLVM Discussion Forums](Release Announcement)
FYI llvm 17.0.1 is available in HaikuDepot
Thanks for the work on this monster
any good ideas, what cool stuff we could build with the shiny new llvm-clang toolchain?
I wouldn’t call it ‘cool’ but it would be nice if the
haiku-format tool was updated to the latest version of llvm/clang. I looked at the repository for it a few weeks ago but it seemed like a mess.
I am always interested in the analyzers and sanitizers myself.
clang-format looks to have had some good changes.
It would be really good to have the sanitizers available on Haiku but as I understand some more porting would be needed for that. Current recipe has
COMPILER_RT_BUILD_SANITIZERS set to
Interesting, I wonder why?
i guess stuff like ptrace and procfs
As the post opened as Off Topic category
I dare to share a funny misunderstanding and association when I was red here on forum about ‘Clang’ …
This is because I am rather a trekkie than a coder…
So for reading Clang I had not analyzed as I had not known as a C language alternative but associated a klingon warrior,
In the STAR TREK series - ENTERPRISE - episodes.
(First honestly my memory tricked me : I remembered as it would be the name of one of famous dahar masters … but they are really named
and the one and only I remembered well :
Speaks to my excuse : all these klingon names
starts with ‘K’, and I was really sure : the three of them are such way … that I remembered well !.. 8D
This is maybe due to Kahless … beginning a klingon name with a ‘K’ … more glorious and honored - )
… But back to my “crosstalk” …
klaang, which pronounced similarly Clang … as if someone reads the beginning C = K primarily in English.
Without any following, modifier letter like in case ‘CH’
However now I know exactly what it is … this association engraved in me - so first impression and thought is about a klingon warrior and read it in my mind as the name of it - not
C language :))
Also LLVM, when I first saw in HaikuDepot … I was happy : good :
Logical Volume Manager was ported to Haiku "!..
Of course when I clicked and opened the details … so this is really rather a development framework … then I thought some not too nice about English acronyms and their inventors. :\
Then I had not read yet about what more Haiku devs thinks and shares as conviction about additional software layers between progs and HW within OS - that’s against Haiku goal as speedy run and efficiency.
Later I met with it on forum and accepted - so now I know :
it is hardly get into Haiku in the near future :j
I assume as it is a like suspicious server-like feature : to enlarge storage without reboot.
I can imagine workstation grade Haiku installs … especcially in case 64 bit Haiku, where some virtualization would be welcomed.
Moreover if the ‘desktop’ not a developer SBC , but a workstation with a Xeon or Threadripper or other Ryzen like multicore monsters with mass amount of memory - I assume a Blender or a personal buildmaster machine would be a graceful for broader HW resources.
But here I close my sentences - it would have been about my funny “misunderstood, failing hearings” : )
also not to forget about Kling Klang Studio
It depends at which version of the repository you look at.
During a past GSoC project we made a repo that’s more standardized: GitHub - viveris/llvm-project at haiku-format-10.x
There is also work there to rebase haiku-format changes on newer versions of clang-format, for example GitHub - viveris/llvm-project: The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. Note: the repository does not accept github pull requests at this moment. Please submit your patches at http://reviews.llvm.org. or GitHub - saloniig/llvm-project: The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. Note: the repository does not accept github pull requests at this moment. Please submit your patches at http://reviews.llvm.org. (I don’t remember the exact status of the branches). However, after rebasing, there were various regressions that should be fixed, the code formatting was not working fully correctly anymore.
As an experiment, we tried to apply haiku-format to the same version of the Input preferences with the 10.x and the then new version of haiku-format, to identify the regressions, you can find the result of these tests here:
with comments about things that need to be fixed in each of these versions.
If someone plans to work on this, you should coordinate with @owenca who made most of the initial work on haiku-format and is still contributing to clang-format on llvm side since then. Ideally, all the things we need should be integrated into upstream clang-format, and then haiku-format would just be a config file for clang-format. But this might mean changing the coding style in some places, where our current formatting rules end up being quite hard to automate, and the output of current clang-format versions would be just fine.
any previous work on the sanitizers?
I looked at the repository for it a few weeks ago but it seemed like a mess.
There are two repos:
- GitHub - owenca/haiku-format for quickly building
- GitHub - owenca/llvm-project at haiku-format for continued development
Which one did you look at?
Probably the latter. I don’t recall seeing the first one before.
clang-format looks to have had some good changes.
Indeed, especially since clang-format 15. I’ll upgrade
haiku-format to clang-format 17.0.1 soon because there are a number of new options e.g. InsertBraces (when combined with RemoveBracesLLVM), IntegerLiteralSeparator, InsertNewlineAtEOF, LineEnding, RemoveParentheses, etc. which may be relevant to the Haiku coding style.
The major changes from clang-format 10 to haiku-format were in this commit. Did you have trouble making sense of it? Or did you have problems with the clang-format source code in general?
IMO it’s extremely unlikely, unless Haiku is willing to remove the requirements of putting the constructor initializer colon on its own line, ordering and aligning class member specifiers, etc.