hylo-lang / swifty-llvm Goto Github PK
View Code? Open in Web Editor NEWSwifty interface for the LLVM compiler infrastructure.
License: Apache License 2.0
Swifty interface for the LLVM compiler infrastructure.
License: Apache License 2.0
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
struct
s, 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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.