- make the int size configurable in the `runWasm` call, no more
constants to hunt down and change
- make storeU64 and storeI64 handle bigints, this is needed in the
odin_dom library
- fix alignment issues within init_event_raw
LLVM generates calls with `i32` regardless of target, so if a call to
any of these procs was generated this failed to compile.
I opted to fix by changing from `int` to `i32` on wasm64p32 and adding
`#any_int` so existing code keeps working.
Clipboard is an optional addition to the microui functionality, but the
init function makes it look like it is required. Additionally, a bunch of
the examples both on the Odin-Lang/examples repo and others are now
"broken".
Got a report on Discord that the current way didn't work for a user,
this change did work and I confirmed with @harold-b (who initially added
this) that it also works for them and is actually a better way.
A few reports of either people not having this clang++ or having it but
it not finding system headers. On top of that, the reason we added this
in the first place was a bug that surfaced on clang-18 which we've since
fixed.
Order will now be clang++ from path, then the llvm bindir clang++, then an
error.
This can all still be overwritten with `CXX=blah make` like before.
1. fix the `linux.open` call, passing `{ .RDONLY }` becomes `0x00000001`
while `RDONLY` is supposed to be `0x00000000`
2. fix the case where `/etc/os-release` starts with `PRETTY_NAME`
`strings.index` was used but was checking `> 0` while `0` is valid
3. remove unneccesary temporary allocations
4. simplify the logic
Returns the actual error if one is set, instead of swallowing it for the
less descriptive negative error.
Also fixes a out-of-bounds slice error in `bufio.writer_write` because
it wasn't checking the returned `m`.
Because we currently just use the clang from the user's path linking
suddenly breaks when the user updates their system clang to 18 with an
error about an unknown option -arch.
I had already fixed it for my LLVM 18 PR but it seems like a good idea
to get this in already to avoid that breakage (had a few people come to
the Discord with it and an issue).
This fixes#3461
I verified the PR by running the entire test suite of Odin itself with
`-sanitize:address` and also the ols test suite (which caused unique problems
before).
A test has also been added with some problematic code, Windows seems to
have problems with asan in CI or in general so it is not ran there.
The LB_ABI_COMPUTE_RETURN_TYPES block has been removed entirely because
it was unused, I got pretty confused why it didn't effect anything at
first.
Fixes#3211
Previously `args=1`, `args={}`, `args={1, 2, 3}` would all crash the
compiler. Now it passes them correctly, and if given a compound literal,
the values are expanded into the call so you can use a named arg while
passing multiple values.
Fixes#3168
This fixes (on my end) #3340, #3117, #2945, #2922, and #2762
A general refactor of debug info generation in order to fix issues and
increase stability.
What I believe is the root cause of a bunch of issues is that we use the
temporary metadata/forward declarations too much (/ hold onto them for
too long). It seems to cause problems with the reference counting inside
LLVM.
This PR reduces the use of these forward declarations to a minimum, it
creates it, fills in the fields, and resolves it, instead of waiting
until the end of generating code.
Some smaller issues I came across have also been solved.
We did some profiling for #3343 and this seems to be the biggest
problem. `realpath` is expensive, and we are locking here for no reason
that I can think of.
This improves the "check procedure bodies" timing (of the linked issue)
from 2.4s to .4s on my machine.
Trying to fix all linker warnings that macOS comes up with, when
building a dynamic library it currently emits `ld: warning: ignoring -e, not used for output type`
After #3316 we set a default minimum version, now this will warn if you
link with a library that is targeting later versions.
This might be a bit annoying, especially when the user hasn't actually
given Odin a minimum target.
So this PR makes these warnings only show when you explicitly give a
target version (afaik that is the only thing that -mmacosx-min-version
actually does for us because we don't use it to compile anything, just
to link).
Since commit b4fe9677a1 some core tests
segfault during build, upon investigation it is because some arg types
were of size 0 and you can't have a 0 sized int.
It also applies the earlier fix for parameters to the return types, this
fixes#3223
Thought I would put this PR up, but I am in no way an expert in abi so
feel free to close for a better fix if there is one.
I am able to run the entire core test suite with `-sanitize:address`
with these changes.
the required procs within wasm would compile to take native v128
arguments in, but the procs are supposed to take in i64's causing bad wasm
modules.
Fixes#3263
`path_to_fullpath` did different things on Windows&Unix, an attempt to
bring them closer together was made here.
This was prompted by the compiler completely ignoring
`foreign import "foo.dylib"` when `foo.dylib` does not exist (because
`path_to_fullpath` returns an empty string).
Causing just unresolved symbol errors, when on Windows it would pass
along the path to the linker and actually say it doesn't exist, which
is now also the case for Unix.
This also fixes some checker errors that relied on the Windows
behaviour, for example: `Error: File name, , cannot be as a library name
as it is not a valid identifier`.
Made `-no-crt` require either `-default-to-nil-allocator` or
`-default-to-panic-allocator` on Unix, the current default allocators
rely on libc and this was not obvious and would immediately bring up
unresolved symbol errors for the linked memory management functions, or
just link with libc anyways because it was foreign imported.
Added a suggestion to install `nasm` with the user's package manager
when assembling using `nasm` fails on Unix, I saw some confusion about
it in the Discord.
Ignore explicit foreign imports of libc. It is already linked in later
on in the linking process and would otherwise (at least on macOS) cause
linker warnings for duplicate libraries. This also makes it so when
using `-no-crt` and importing something that requires libc, linker
errors are given (like I would expect), instead of silently still
linking with libc because it was foreign imported.
Laytan Laats