implicit conversion error 'unsigned int' to 'long' in Sema.cpp about oberon-lang HOT 9 CLOSED

I've added an explicit type cast in the lastest batch of bug fixes. I hope that makes this problem disappear. Unfortunately, it does not occur with any of my platforms/compilers and, therefore, I am flying a bit blind here.

from oberon-lang.

I am guessing this is a bug/regression on the MSYS2 platform.
Maybe just encapsulate this in:

#if defined(MINGW32)
and add a note about possible bug and I can try again in future releases of CLANG.

from oberon-lang.

How can I install the MSYS2 platform to test whether my work-around works?

from oberon-lang.

Download the installer at : link

Open the shell for CLANG64 : C:\msys64\clang64.exe

pacman -S mingw-w64-clang-x86_64-toolchain
pacman -S mingw-w64-clang-x86_64-boost
pacman -S mingw-w64-clang-x86_64-cmake
pacman -S mingw-w64-clang-x86_64-python
pacman -S mingw-w64-clang-x86_64-python-pip
pacman -S make
pacman -S git
pip3 install --user lit
pip3 install --user filecheck
For me this install files to C:\Users\rute.local.
Move this files to ~/.local and ~/.local/bin to path:
export PATH="$PATH:~/.local/bin"
git clone https://github.com/zaskar9/oberon-lang.git
cd oberon-lang/
mkdir cmake-build-release
cd cmake-build-release
cmake .. -G "MSYS Makefiles"
make
make test

I was thinking now that the unittest is up and running the above step and similar
steps for other platforms could be added as a CI Workflow.

I can look at this if you agree this would be useful.

from oberon-lang.

New similar error in the latest updates:

C:/msys64/home/rute/dev/oberon-lang/src/codegen/llvm/LLVMIRBuilder.cpp:996:23: error: comparison of
integers of different signs: 'long' and 'unsigned int' [-Werror,-Wsign-compare]
996 | if (value >= arrayTy->dimensions()) {
| ~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~
1 error generated.

from oberon-lang.

Hopefully, this is fixed in the latest pull-request that I just merged. But let me know if new problems of this type have popped up. This feels a bit like playing "whack-a-sign-error". 😎

The major change of the latest pull-request is support for CHAR (and dropping support for STRING). This was a major operation, due to silly design choices (e.g., not distinguishing syntactically between string and character literals or having the LEN built-in procedure for arrays). Arrays are now stored as structs { length, vector[] } and code is generated to initialize all the length values. The compiler now also has an option to enable array bound checks (-fenable-bound-checks). This will generate code to check indexes at run-time, if they cannot be checked at compile-time. The length of the array is only read from the struct as a last resort, if the compiler cannot get it from type information. All-in-all, this pull-request brings significant changes to all components of the compiler, but I hope that it is more or less production-ready nevertheless. Note that the standard library will need to be recompiled. Out.String no longer uses printf! The level of platform independence is rising!

The pull request also brings the failing unit tests down to only 5. 🎉

from oberon-lang.

This is excellent.
I will add some further unittests covering the new features added lately.

With regards to bounds check it could be possible to utilize the same infrastructure as CLANG uses.
e.g. call __ubsan_handle_out_of_bound for full reporting or just llvm.ubsantrap for trap behaviour with error code.

I looked a bit into diffs of what CLANG does add here and it could be an idea to implement something similar?

The LLVM documentation is a bit sparse in this area.
I found a blog with a nice write-up of this : link

from oberon-lang.

Thanks for this information! I suspected LLVM had something like that, but wasn't able to quickly find it. The LLVM documentation is not just sparse in this area, it's generally sparse when things become interesting! 😵‍💫 The best thing is often to write C code that simulates the desired Oberon behavior and then inspect the LLVM IR that clang generates.

However, I will keep this in mind as a possible improvement! For the time begin, I am happy with the current solution, in particular that it can be turned off as it makes the IR unreadable. 😎 Since Oberon has the LEN built-in procedure, I need to wrap arrays in a struct and carry the length information around anyway. So, I have this information around to check bounds, if I'm looking at an open array. I was also thinking of adding C-style arrays (that do not support LEN) back in for performance reasons, using the syntax v: INTEGER[256]. Again, that's an idea for the future.

Another issue here is that the trap numbers that the Oberon standard assigns to certain conditions (26.7. Run-time traps in: https://people.inf.ethz.ch/wirth/Oberon/Oberon.ARM.Compiler.pdf) do not align at all with POSIX signals. My plan is to be POSIX compliant and, for example, raise SIGSEGV when an array is accessed out of bounds, rather than 1, which in POSIX terms would be SIGHUP and thus very confusing for the developer.

from oberon-lang.

I found that the code for the tools in the LLVM project actually is quite good, well commented, where the documentation sometimes is confusing or lacking.

With regards to generation of trap, malloc, free and the other external procedures which now is hardcoded into the code generator. I was thinking maybe it could call out to a Oberon module (ex. called OberonRST).
For example when the out of bounds trap is called with OberonRST.Trap.
I can choose to replace this module which then generates a ARM SVC call instruction.
Even a simple garbage collector could be added by replacing malloc and free with the GC drop in equivalents link

from oberon-lang.