`getError()` now returns a struct `Error` containing `error_code` and
`description`. Rationale: retrieving the error code with the previous
implementation of `getError()` caused `getErrorString()` to return
null (the reverse is also true). The new implementation allows both
values to be retrieved at once.
The previous `getError()` function has been renamed to
`getErrorCode()` to reflect the fact that it returns a simple Zig
error rather than the `Error` struct. The error set returned by
`getErrorCode()` is now named `ErrorCode` rather than `Error`.
The behavior of the `getError()` family of functions clearing the
stored error is unchanged. However, since all code that used
`defer glfw.getError() catch {}` to explicitly clear errors had to be
refactored, a new `glfw.clearError()` function that returns void is
now available to make this operation more explicit.
Additionally, `mustGetError()` is now `mustGetErrorCode()`, and new
functions `mustGetError()` and `mustGetErrorString()` have been added
which wrap `getError()` and `getErrorString()` but panic if no error
is actually available.
Tests and API documentation had to be refactored across all of
`mach/glfw`. This commit also takes the opportunity to skip tests
involving window creation on CI so that other tests may still execute
normally.
Since users of the library do not have access to the `@cImport` struct (and we
do not want to expose that), the user may pass only an untyped `*anyopaque` pointer
which we'll internally cast to `*c.GLFWwindow`.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
This change both restricts and clarifies the mutability/nullability of the pointers, and replaces the explicitly-typed pointer usage in setUserPointer with ?*anyopaque, since it now, as of being renamed from c_void, more simply communicates the intent of taking any pointer type.
This consistently shaves off about 40ms (~130ms -> ~90ms, 30% reduction) from build times when iterating.
On Windows, I suspect the result will be much greater due to slow filesystem perf there and the fact
that this reduces the # of files read.
This was originally brought to my attention as a possibility by @meshula in hexops/dawn#2, the way this
works is by reducing compilation units so that C headers only need to be read/parsed/interpreted once
rather than once per individual C source file we are compiling.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
The latest Zig master supports specifying a specific macOS version for libc, via
the target triple (ziglang/zig#10215):
* x86_64-macos.10 (Catalina)
* x86_64-macos.11 (Big Sur)
* x86_64-macos.12 (Monterey)
* aarch64-macos.11 (Big Sur)
* aarch64-macos.12 (Monterey)
Mach's `system_sdk.zig` can now download the relevant XCode framework stubs
for Big Sur (11) and Monterey (12). Although we don't have an SDK for Catalina (10)
currently, we use the Big Sur (11) SDK in that case and it generally works fine.
By default, Zig targets the N-3 version (e.g. `x86_64-macos` defaults to `x86_64-macos.10`).
Targeting the minimum supported version is useful for compatability, it guarantees the produced
binary will run on any later macOS version. Targeting the newer version can be useful if you
wish to use newer APIs not available in previous versions.
Fixeshexops/mach#102
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
* glfw: window hint default values parity test with attributes
* glfw: add test-mode-only variable that controls whether to set or ignore the `Window.Hints` struct passed to `Window.create`, and inline `failedToCreateWindow`
* glfw: include `context_no_error` hint/attribute in test with comment, fix oversight in `create` concerning the `defer defaultHints()` statement
Co-authored-by: Stephen Gutekanst <stephen.gutekanst@gmail.com>
