Clang Compilation failure

[Sid911]

Hi, I was recently trying to run flux on clang, this can be easily replicated by visiting https://flux.godbolt.org/ and using clang trunk which I assume is 18.1.0 (https://flux.godbolt.org/z/6x7G8n6G1) but the stacktrace is here for Clang 19 experimental build if anyone is interested.

I am not sure if this is clang issue or flux but I hope this get resolved soon enough.

[tcbrindle]

Oh dear, this isn't good :(

This is clearly a Clang bug (we shouldn't be able to crash the compiler just by #include-ing a header!) but we'll still need to work around it in Flux as it looks quite bad otherwise

[tcbrindle]

With #175 merged, it appears we now avoid the compiler bug: https://flux.godbolt.org/z/PcedMazhb

(Note that godbolt.org updates once a day AFAIK, so it will take ~24 hours or so for this to be reflected in the version of Flux available in the Libraries menu)

Thanks for reporting this @Sid911!

[Sid911]

Thanks for having a work around it so soon, I was wondering what you think was the reason that replacing with FLUX_FOR fixed the issue @tcbrindle?. Also, I was able to verify this for clang 18 and 19 with intel icpx 2024.0.2 too. I will try to report this to llvm project, to see if this can be fixed.

[tcbrindle]

Previously the code used a range-for loop, which required wrapping the Flux cursors with STL-compatible iterators. I saw a reference to begin in your backtrace (thanks!) and thought that maybe if I could avoid iterators, it would avoid the bug. Luckily it worked! (And as a bonus, the version using FLUX_FOR is actually simpler on all platforms as it avoids a layer of abstraction, I really should have done it that way to start with...)

I don't know what underlying cause might be, it's very unusual in my experience for a Clang front-end bug like this to make it into a released version.