Cxx interop problem

[postmechanical]

Expected behavior

Using swift-nio package in a project with Cxx interop enabled builds, runs, and is debuggable.

Actual behavior

Using swift-nio package in a project with Cxx interop enabled builds and runs but renders debugger unusable with following error:

(lldb) po someVar
error: /Users/some.user/Library/Developer/Xcode/DerivedData/SomeProject-ejsisrcmvvxjfmgjdseiwglvudot/SourcePackages/checkouts/swift-nio/Sources/CNIOLLHTTP/include/c_nio_llhttp.h:3:1: import of C++ module 'std_stdint_h' appears within extern "C" language linkage specification
#include <stdint.h>
^

Locally modifying c_nio_llhttp.h as follows builds, runs, and is debuggable:

13a14
> 
15c16,18
< extern "C" {
---
> #include <cstdint>
> #else
> #include <stdint.h>
18c21,23
< #include <stdint.h>
---
> #ifdef __cplusplus
> extern "C" {
> #endif

Steps to reproduce

I have attempted a standalone repro without success so far. The project in which I've enabled Cxx interop is a sizeable legacy project that is a mix of UIKit and SwiftUI.

At the project level I have added -cxx-interoperability-mode=default -Xcc -std=c++17 to the OTHER_SWIFT_FLAGS build setting. I have one local package that depends on grpc-swift which transitively depends on swift-nio and this local package does not enable Cxx interop. I have another local package that depends on a remote package that requires Cxx interop and is using swiftSettings: [.interoperabilityMode(.Cxx)] on the target definition and cxxLanguageStandard: .cxx17 on the package definition.

If possible, minimal yet complete reproducer code (or URL to code)

No minimal standalone repro yet.

SwiftNIO version/commit hash

2.78.0

System & version information

Please provide at the very least your operating system and Swift version
information.

macOS: 14.7.1
Swift: 5.9
Xcode: 16.2 (16C5032a)

Ideally, run

scripts/nio-diagnose -o nio-diagnose.md PID_OF_YOUR_NIO_PROGRAM

and attach (or paste) the resulting file nio-diagnose.md into this bug report
or send it to the SwiftNIO maintainers privately.

[Lukasa]

Thanks for filing this! Is this the only change required to get things to build on your end?

If so, then I think there are two steps. First, ideally you'd file a bug report on llparse, which generates the header file. The include comes from here, and could easily be guarded appropriately.

Secondly, we can apply a patch to the generated code here to get this to work.

[postmechanical]

It is the only change to get the debugger working again on my end. I will get started on the suggested next steps. Thanks.

[Lukasa]

No problem, please let me know if you need any help.

[postmechanical]

Issue created over at llparse: nodejs/llparse#71