The comments that were added automatically in odin site, contained
tabs, so the first line of a two line comment was properly rendered in
the site, but the second line of the comment (because it included tabs
in the beginning of the line) was rendered as preformattted text. I
think that the proposed changes will fix this problem in the
documentation site.
An example of the problematic rendering of documentation is
https://pkg.odin-lang.org/core/compress/#COMPRESS_OUTPUT_ALLOCATE_MAX
Using `system:miniaudio` is suboptimal, we already provide the
`Makefile` that builds the `lib/miniaudio.a` and this works on MacOS.
This PR makes linking with that library the default.
The LLVM intrinsics that live under `llvm.x86` are not actual functions,
so trying to invoke them as such using the platform's native C
calling convention causes incorrect types to be emitted in the IR.
Thanks to laytanl for assistance in testing.
`llvm_features` being empty is the default state, and implies the
presence of certain features.
Previously if any target features were explicitly enabled by the
`enable_target_feature` attribute, they were added comma separated
to `llvm_features`.
For example: `lzcnt,popcnt,...,sse4.2,sse`
This was causing LLVM to try to target a CPU that *ONLY* has the
explicitly enabled features. This now will prefix explicitly enabled
features with a `+`, and preserve the existing `llvm_features` string
by appending to it if it is set.
```
package example
import "core:dynlib"
import "core:fmt"
Symbols :: struct {
// `foo_` is prefixed, so we look for the symbol `foo_add`.
add: proc "c" (int, int) -> int,
// We use the tag here to override the symbol to look for, namely `bar_sub`.
sub: proc "c" (int, int) -> int `dynlib:"bar_sub"`,
// Exported global (if exporting an i32, the type must be ^i32 because the symbol is a pointer to the export.)
// If it's not a pointer or procedure type, we'll skip the struct field.
hellope: ^i32,
// Handle to free library.
// We can have more than one of these so we can match symbols for more than one DLL with one struct.
_my_lib_handle: dynlib.Library,
}
main :: proc() {
sym: Symbols
// Load symbols from `lib.dll` into Symbols struct.
// Each struct field is prefixed with `foo_` before lookup in the DLL's symbol table.
// The library's Handle (to unload) will be stored in `sym._my_lib_handle`. This way you can load multiple DLLs in one struct.
count := dynlib.initialize_symbols(&sym, "lib.dll", "foo_", "_my_lib_handle")
defer dynlib.unload_library(sym._my_lib_handle)
fmt.printf("%v symbols loaded from lib.dll (%p).\n", count, sym._my_lib_handle)
if count > 0 {
fmt.println("42 + 42 =", sym.add(42, 42))
fmt.println("84 - 13 =", sym.sub(84, 13))
fmt.println("hellope =", sym.hellope^)
}
}
```
