hylo-lang / swifty-llvm Goto Github PK

This seems to be a problem with my configuration, but I have no idea because I haven't had much contact with LLVM.
So what I've added to README about Windows is probably not comprehensive enough.

C:\Users\19454\Desktop\Swifty-LLVM [main ≡]> swift test
warning: failed to retrieve search paths with pkg-config; maybe pkg-config is not installed
warning: couldn't find pc file for llvm
Building for debugging...
lld-link: error: could not open 'llvmc.lib': no such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)
[6/7] Linking C:\Users\19454\Desktop\Swifty-LLVM\.build\x86_64-unknown-windows-msvc\debug\Swifty-LLVMPackageTests.xctest
error: fatalError

CI for Windows: https://github.com/C-BJ/Swifty-LLVM/actions/runs/4438689100/jobs/7790088981

Could you give me some advice to try? @kyouko-taiga

It /should/ be possible to do something like this in the Dockerfile directly (after moving make-pkgconfig into .devcontainer/ and optionally symlinking from Tools/):

ARG HYLO_LLVM_BUILD_TYPE=MinSizeRel
ADD make-pkgconfig.sh /tmp
RUN <<EOT bash
set -ex
set -o pipefail
PATH="/opt/llvm-\${HYLO_LLVM_BUILD_TYPE}/bin:\$PATH" \
     /tmp/make-pkgconfig.sh /usr/local/lib/pkgconfig/llvm.pc > /dev/null
rm /tmp/make-pkgconfig.sh
EOT

but it hasn't worked so far

If this is ever going to land, we'll need to fix this project for Windows and of course it should be tested in CI.

I suspect we can rework the API to avoid exposing any of the reference wrappers defined in Refs.swift. Those are completely useless unless one can access the value of the LLVM pointer or enum being wrapped and use it to call the C API directly. As the intent of the current setup is to keep llvmc internal, using that API outside of SwiftyLLVM is not possible.

When I start up an arm64 devcontainer and do swift test, the process often hangs at

Test Case 'IRTypeTests.testIsSized' started at 2024-03-01 20:31:31.110

Just the first time. Running it again works fine.

Actually different tests hang each time, and it hangs for about 50% of the subsequent runs.

I can build in release mode as described in the readme file. But if I try debug build I get the following:

$ swift build -c debug
Building for debugging...
clang-16: error: unknown argument: '-index-store-path'

Any pointers on how to resolve this?

In .build/debug.yaml I see

    description: "Compiling llvmshims src/shim.cc"
    args: ["/opt/homebrew/opt/ccache/libexec/clang",...,"-index-store-path"]

which is not part of .build/release.yaml

That would make the build cleaner.

This comment demonstrates the crash.

https://github.com/swiftlang/swift-llvm-bindings appears to be getting some maintenance attention. I don't know if this is something we've already looked at.

The tool requires an argument.

Assertion failed: Val && "isa<> used on a null pointer", file S:\src\llvm-17.0.6\llvm\include\llvm/Support/Casting.h, line 109

We should be able to go from

let a = Parameter.Attribute(.zeroext, in: &m)
m.addAttribute(a, to: f.parameters[1])
m.removeAttribute(a, from: f.parameters[1])

to

let a = m.addAttribute(.zeroext, to: f.parameters[1])
m.removeAttribute(a, from: f.parameters[1])

Causes an LLVM built with assertions on to assert:

Assertion failed: Val && "isa<> used on a null pointer", file S:\src\llvm-17.0.6\llvm\include\llvm/Support/Casting.h, line 109

We have lots of checks like this:

    XCTAssert((t as IRType) == t)

When that fails, it fails to give some useful information. Should be:

    XCTAssertEqual(t as IRType, t)

Do this throughout.

We need to update the instructions; we now require LLVM-17. We should recommend the use of our prebuilt binaries.

In order to avoid exposing llvmc to clients, #47 wrapped all public properties named llvm, whose type was defined in llvmc, in public structs, with the underlying value being accessed via a .raw property. This leaves us with many private/internal properties named llvm that have no .raw property, which makes usage a bit confusing. With some thinking a better arrangement is likely possible. We could probably benefit by putting even the private/internal properties in wrappers, because right now they are all OpaquePointer instances and the wrappers add some static type safety.

The names llvm and raw are not great either, so it would be good to adjust those if possible.

I had to disable Windows CI because I got failures trying to compile some shims for the LLVM C API. The problem appears to be that we should manually specify what libraries to link in Package.swift. See https://github.com/val-lang/Swifty-LLVM/actions/runs/4873453734

@C-BJ, maybe you'd like to take a look?