search

boost-ext / di

C++14 Dependency Injection Library
https://boost-ext.github.io/di
1.16k stars 140 forks source link

DI fails to build with clang 18.1 #568

Open zybreak opened 3 weeks ago

zybreak commented 3 weeks ago

Expected Behavior

di.hpp should not cause compilation failures

Actual Behavior

just including di.hpp causes the compilation to fail di.hpp:2104:42: error: token is not a valid binary operator in a preprocessor subexpression di.hpp:2127:42: error: token is not a valid binary operator in a preprocessor subexpression

The offending line(s) are #if (defined(__CLANG__) && __CLANG__ >= 3'9)

It seems clang 18 does not like the 3'9 expression

Steps to Reproduce the Problem

  1. create a empty main function, include di.hpp
  2. compile with clang 18.1

Specifications

zybreak commented 3 weeks ago

changing the line to CLANG >= 4 enabled me to compile di.hpp as a temporary workaround for anyone else in the same situation in lieu of a proper fix

krzysztof-jusiak commented 3 weeks ago

Hi @zybreak, thank you for reporting the issue. I've been trying to repro it but I think I'm missing something. The following https://godbolt.org/z/7z6x57GeY seems to be okay with clang-18.1. Could you please share godbolt and/or your setup? thanks.

zybreak commented 3 weeks ago

This might be on me, It fails in my project but works when tested in isolation. I'll close this bug report and reopen if I find there is some special case where the above does indeed fail.

Sorry for taking your time

krzysztof-jusiak commented 3 weeks ago

no worries @zybreak , thanks for letting me know and feel free to reopen if needed.

zybreak commented 3 weeks ago

Hi again, I had another look at this and I now understand what the problem is.

I got a minimal project up that reproduces this here https://github.com/zybreak/di-test

So the problem is that the code fails when dependency scanning is turned on, which CMake has turned on by default in newer versions for c++20 and above.

I have no real clue as to why the header is interpreted differently when dependency-scanning.

Hope this helps