GitHub CI build and testing

[EndeyshentLabs]

TODO:

• Basic build on generic linux (ubuntu-latest)
• Windows build
• Testing suite
• Compiler test
• Conditional run (or not-run) based on commit message

Hopefully, will catch compiler incompatibilities quicker than the users.

[EndeyshentLabs]

The Windows build fails inside of C++ header <memory> with 24 MiB log with 221268 lines.

[EndeyshentLabs]

GitHub's ubuntu-latest is Ubuntu 24.04 and uses LLVM v18 (from 2024) so it's basically useless.

[LensPlaysGames]

I hate Ubuntu for exactly that reason
who is using software from 5 years ago??

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    container:
      image: fedora:latest

I've been seeing something like this online but, I really have no clue about this CI stuff.

Fedora at least has up to date tools

[LensPlaysGames]

Lots and lots of
D:\a\LensorCompilerCollection\LensorCompilerCollection\bld\libs\fmt\include\fmt\base.h(1224,45): warning: enumeration type in nested name specifier is incompatible with C++98 [-Wc++98-compat]

Er, why is it trying to compile c++98 compatible?

[LensPlaysGames]

I had a local AI yell at me about this

The problem is that clang-cl triggers both if (MSVC) and if (CMAKE_CXX_COMPILER_ID STREQUAL "Clang") blocks inside CMake, but it uses MSVC-style command line arguments.

[LensPlaysGames]

Apparently latest is not the latest. Thanks macrohard
runs-on: ubuntu-26.04 llvm 21/22 and gcc 15

[LensPlaysGames]

I had a local AI yell at me about this

The problem is that clang-cl triggers both if (MSVC) and if (CMAKE_CXX_COMPILER_ID STREQUAL "Clang") blocks inside CMake, but it uses MSVC-style command line arguments.

Looks like we could use
https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_SIMULATE_ID.html
Or
https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER_FRONTEND_VARIANT.html

[EndeyshentLabs]

I hate Ubuntu for exactly that reason who is using software from 5 years ago??

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    container:
      image: fedora:latest

I've been seeing something like this online but, I really have no clue about this CI stuff.

Fedora at least has up to date tools

I will look into that bit later. I was able to successfully build LCC locally on the fedora:latest image.

[EndeyshentLabs]

Apparently latest is not the latest. Thanks macrohard runs-on: ubuntu-26.04 llvm 21/22 and gcc 15

This is so bad, are they """testing""" images or something before making them latest? How do you even do that, aren't these ubuntu images pulled straight from docker or something?

[EndeyshentLabs]

I almost want to close this PR, this is so bad. On sourcehut the images for are always up to date, can't multi-billion dollar corporation achieve this?

[EndeyshentLabs]

I say almost, because it will be useful for catching compiler (LLVM) stupidity.

[LensPlaysGames]

Apparently latest is not the latest. Thanks macrohard runs-on: ubuntu-26.04 llvm 21/22 and gcc 15

This is so bad, are they """testing""" images or something before making them latest? How do you even do that, aren't these ubuntu images pulled straight from docker or something?

https://docs.github.com/en/actions/reference/runners/github-hosted-runners

Note
The -latest runner images are the latest stable images that GitHub provides, and might not be the most recent version of the operating system available from the operating system vendor.

[LensPlaysGames]

I hate Ubuntu for exactly that reason who is using software from 5 years ago??

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    container:
      image: fedora:latest

I've been seeing something like this online but, I really have no clue about this CI stuff.

Fedora at least has up to date tools

I will look into that bit later. I was able to successfully build LCC locally on the fedora:latest image.

You can run actions locally?

[EndeyshentLabs]

No, I just use docker.

[EndeyshentLabs]

It is close-enough to actions.

[EndeyshentLabs]

Could we get away with doing the if (fail) return 1; behind either a preprocessor define or command line flag?

I've seen people doing that, so we could do that.

[EndeyshentLabs]

There are problems with shadowing PrintMIR:

In file included from /LensorCompilerCollection/lib/lcc/calling_convention.cc:7:
/LensorCompilerCollection/inc/lccbase/context.hh:50:9: error: declaration shadows a variable in namespace 'lcc' [-Werror,-Wshadow]
   50 |         PrintMIR = true,
      |         ^
/LensorCompilerCollection/inc/lcc/codegen/mir.hh:555:6: note: previous declaration is here
  555 | auto PrintMIR(const std::vector<std::unique_ptr<GlobalVariable>>& vars, std::vector<MFunction>& mcode) -> std::string;
      |      ^

[EndeyshentLabs]

GitHub is falling apart with this PR, because it required me to resolve some non-existent merge conflict and the resolve commit is empty lol.

[LensPlaysGames]

Lmao not windows passing and Linux failing now 💀

[LensPlaysGames]

Also, clearly I fucked up the clang-cl build warnings config...

These need to also apply to msvc-like clang
https://github.com/LensPlaysGames/LensorCompilerCollection/blob/main/CMakeLists.txt#L253-L255

[LensPlaysGames]

The amount of projects this stupid choice has affected is, well, stupid
llvm/llvm-project#102982

[LensPlaysGames]

I'm curious, what is the motivation behind the tests failing also failing the CI?

I feel like, when developing a new language, it's quite common for the tests to outrun the implementation.

Is the idea that the main LCC repository+branch only gets commits at official releases?

Or, is the idea that CI failing isn't something to be looked at, it's more for later users to go back and see which commits contain "working" compiler?

I guess I just don't understand our goal of CI, or how I'd go about using it 👀

Edit: I think the compiler not building on a platform we want to support (even secondarily like macrohard) should definitely be like a "panic"/"fix me before moving on" situation, whereas tests failing usually have to do more with language frontends, or their interactions with the compiler, and not the compiler itself. Is the CI for compiler developers or language developers, or both?

[LensPlaysGames]

btw, er, thank you, and I'd be okay with merging this anytime

[EndeyshentLabs]

I feel like, when developing a new language, it's quite common for the tests to outrun the implementation.

Yes, you're right. Maybe tests shouldn't fail the CI after all, because it will become super noisy, especially considering the current state of the development, where test are failing, but "this is fine". One can check CI logs anyways, they're preserved for up to 3 months. Might as well make the test CI opt-in instead of opt-out.

[EndeyshentLabs]

Might as well make the test CI opt-in instead of opt-out.

What do you think about this?

[LensPlaysGames]

Might as well make the test CI opt-in instead of opt-out.

What do you think about this?

I like. So, building on different platforms would be automatic, but tests CI could be run only for like "polished" commits? Or maybe just by language developers... We could always split the test suites, run irtest and code test but skip langtest and run test, if we really wanted. But that's not super important to me

[EndeyshentLabs]

Putting [ci-run-tests] anywhere in the commit message will run the tests.

[EndeyshentLabs]

I think this is ready for merge.