error: declaration '__builtin_trap' attached to named module 'Invariant' can't be attached to other modules

[chriselrod]

/path/to/project/mod/Utilities/Invariant.cxx:18:5: error: declaration '__builtin_trap' attached to named module 'Invariant' can't be attached to other modules
   18 |     __builtin_trap();
      |     ^
/usr/lib/gcc/x86_64-redhat-linux/14/../../../../include/c++/14/array:74:49: note: also found
   74 |        _Tp& operator[](size_t) const noexcept { __builtin_trap(); }
      |                                                 ^
1 error generated.

This is a regression compared to clang 18.1.6 or llvm/llvm-project#66462.

My code calling __builtin_trap() no longer compiles with this branch of clang++.

I am also getting this for modules that instantiate class templates declared/defined in other modules (when this worked with older versions of clang++).

[ChuanqiXu9]

Can you provide a reproducer or at best a minimal reproducer?

[ChuanqiXu9]

BTW, the error message looks not like clangd's error message. If it is from the compiler, please register it in the upstream repo.

[chriselrod]

Yes, that was from clang++ on this branch.
I can reproduce on a recent clang master, so I'll close this.

I'll open an issue on llvm-project if I'm able to get a minimal reproducer, but so far my attempts at a minimal reproducer failed.

[leha-bot]

Sorry, @chriselrod for ping, but did you create an issue in llvm-project? If yes, may you give an issue link please?

Thanks for your attention.

[chriselrod]

I failed to get a minimal reproducer, so I haven't created an issue yet.
I actually no longer saw this, but do see one about builtins such as __builtin_add_overflow.
A perhaps necessary but definitely insufficient condition is that the builtin must be used in at least two separate modules.

One of my dependencies was using these intrinsics, as well as some of my own code. By replacing all uses within my own code with explicitly typed versions (e.g. __builtin_saddl_overflow), I could work around the issue.

But then I got linker errors for some exported module functions. I made one attempt at a minimal reproducer for this, but it also worked fine.
I haven't found a workaround, and have instead went back to working header-only for the time being.
I may switch to header+source file to try and improve my incremental compile times.
The approach I took with modularizing didn't improve these; incremental with modules rebuilding leaves of the dependency tree were already as slow as full rebuilds of the test suite with header-only.
But I'll try and think/read more before making major changes to my code base that may not end up paying off.

Something I didn't take advantage but probably should have are implementation units, to hide implementations.
Ideally, I could use preprocessor macros and some cmakes to make the same source be header+source file vs module interface + module implementation files.
I also think that I want fewer translations units than the number of header files that I have.

import std; may improve things once I switch to cmake 3.30 (I'm currently on 3.28).
My header-only version uses precompiled headers, while I wasn't using them with modules.
Although, I also have headers from dependencies that include in the PCH, for which I'd have to pay the parsing cost with modules -- unless there is a way to use PCH + modules?

[ChuanqiXu9]

I failed to get a minimal reproducer, so I haven't created an issue yet. I actually no longer saw this, but do see one about builtins such as __builtin_add_overflow. A perhaps necessary but definitely insufficient condition is that the builtin must be used in at least two separate modules.

One of my dependencies was using these intrinsics, as well as some of my own code. By replacing all uses within my own code with explicitly typed versions (e.g. __builtin_saddl_overflow), I could work around the issue.

But then I got linker errors for some exported module functions. I made one attempt at a minimal reproducer for this, but it also worked fine. I haven't found a workaround, and have instead went back to working header-only for the time being. I may switch to header+source file to try and improve my incremental compile times. The approach I took with modularizing didn't improve these; incremental with modules rebuilding leaves of the dependency tree were already as slow as full rebuilds of the test suite with header-only. But I'll try and think/read more before making major changes to my code base that may not end up paying off.

Something I didn't take advantage but probably should have are implementation units, to hide implementations. Ideally, I could use preprocessor macros and some cmakes to make the same source be header+source file vs module interface + module implementation files. I also think that I want fewer translations units than the number of header files that I have.

import std; may improve things once I switch to cmake 3.30 (I'm currently on 3.28). My header-only version uses precompiled headers, while I wasn't using them with modules. Although, I also have headers from dependencies that include in the PCH, for which I'd have to pay the parsing cost with modules -- unless there is a way to use PCH + modules?

Yeah, it is suggested to use implementation units to hide implementation more. There is also an option called reduced BMI to help that (https://clang.llvm.org/docs/StandardCPlusPlusModules.html#reduced-bmi).

For rebuilding, there is a WIP in llvm/llvm-project#96453. But end users need the help from build systems to use that.

For PCH + modules, technically it might be fine. But there is not so people tested it. And also personally, I feel it may not be necessary to do that.