i'm a human i think
From Sebastian to ~sircmpwn/hare-dev
On Fri Sep 6, 2024 at 5:33 AM EDT, Alexey Yerin wrote: > The behaviour of `*alias` is different depending on whether it's used > in a tagged union or as a parameter type. For example, passing a > comparison function into sort::sort doesn't need a cast despite the > function type being aliased. This has nothing to do with function parameters; assignability semantics are the same everywhere. The reason for the differing behavior is type hints. When a unary & expression is provided a pointer type hint, and the operand's dealiased type is the same as the dealiased secondary type of the pointer hint, the result of the expression is the type hint. This mechanism currently doesn't work with tagged union type hints. So I don't think there's any dualty in the semantics of type aliases
From Sebastian to ~sircmpwn/hare-rfc
RFC SUMMARY
I propose we add an @align attribute, which will apply in two places:
- Globals: @align(32) let foo = bar { ... };
- Pointers: *@align(8) int
For globals, @align is analogous to alignas in C. The alignment must be
a power of two greater than or equal to the alignment of the type. The
maximum supported alignment is implementation-defined. For pointers,
@align acts as a form of type safety. The alignment can be any power of
two, and it defaults to the alignment of the secondary type if omitted.
LANGUAGE IMPLICATIONS
From Sebastian to ~sircmpwn/hare-rfc
On Mon Aug 12, 2024 at 6:38 AM EDT, Drew DeVault wrote: > Most error handling scenarios are simple and do not suffer especially > much from the strerror convention. Something like a compiler (e.g. > hare-c) has much more complex error handling and reporting requirements, > perhaps by an order of magnitude, than the standard case. As the wisdom > goes, a convention should handle 95% of cases and the remaining 5% > should defy the convention. > > I would sooner prefer that some modules or use-cases for error handling > that exceed the bounds of strerror should establish a parallel > convention for stringifying errors. One example of how this would look > is that something like hare-c just handles errors in a substantially > different manner than the convention affords. For instance, it might be > nice to give harec-style contextual errors like so:
From Sebastian to ~sircmpwn/hare-dev
On Fri Sep 6, 2024 at 11:49 PM EDT, Lorenz (xha) wrote: > On Sun, Sep 01, 2024 at 10:31:07PM -0400, Sebastian wrote: > > The new behavior of type hints in error checking expressions also needs > > to be specified. > > i actually did not change anything with regards to error checking > expressions, i.e. type hints? it still just passes type hint as-is > to the "inside expression". Ah, I missed that this was already a thing. > > Actually, speaking of type aliases, what does your harec patch do if > > alloc is provided a type hint which is an alias of (T | nomem)? If it's > > always dealiased, then when we go through the spec to better specify
From Sebastian to ~sircmpwn/hare-dev
Some of these aren't ever actually misaligned on targets we currently support, since stack-allocated meemory is at a minimum aligned as 4. But it's still good to fix them to not rely on this behavior. Signed-off-by: Sebastian <sebastian@sebsite.pw> --- net/dial/resolve.ha | 5 ++--- net/ip/+freebsd.ha | 5 ++++- net/ip/+linux.ha | 5 ++++- net/ip/+openbsd.ha | 5 ++++- temp/+freebsd.ha | 5 ++--- temp/+linux.ha | 5 ++--- 6 files changed, 18 insertions(+), 12 deletions(-) [message trimmed]
From Sebastian to ~sircmpwn/hare-dev
This is consistent with the macro names in limits.h. All other constants mimick the limits.h names, so these should as well. Signed-off-by: Sebastian <sebastian@sebsite.pw> --- types/c/arch+aarch64.ha | 4 ++-- types/c/arch+riscv64.ha | 4 ++-- types/c/arch+x86_64.ha | 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/types/c/arch+aarch64.ha b/types/c/arch+aarch64.ha index 1c2c9547..eaaf3733 100644 --- a/types/c/arch+aarch64.ha +++ b/types/c/arch+aarch64.ha [message trimmed]
From Sebastian to ~sircmpwn/hare-dev
Signed-off-by: Sebastian <sebastian@sebsite.pw> --- rt/+freebsd/types.ha | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/rt/+freebsd/types.ha b/rt/+freebsd/types.ha index ccb3f6d3..80ec9064 100644 --- a/rt/+freebsd/types.ha +++ b/rt/+freebsd/types.ha @@ -6,17 +6,17 @@ export type suseconds_t = i64; export type dev_t = u64; export type ino_t = u64; export type nlink_t = u64; export type id_t = uint; [message trimmed]
From Sebastian to ~sircmpwn/hare-dev
Signed-off-by: Sebastian <sebastian@sebsite.pw> --- rt/+linux/types.ha | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rt/+linux/types.ha b/rt/+linux/types.ha index aa739484..0e57e61b 100644 --- a/rt/+linux/types.ha +++ b/rt/+linux/types.ha @@ -250,7 +250,7 @@ export type st_flock = struct { l_whence: i16, l_start: i64, l_len: i64, pid: int, [message trimmed]
From Sebastian to ~sircmpwn/hare-dev
Signed-off-by: Sebastian <sebastian@sebsite.pw> --- rt/+freebsd/types.ha | 2 +- rt/+linux/types.ha | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/rt/+freebsd/types.ha b/rt/+freebsd/types.ha index 009b5d31..ccb3f6d3 100644 --- a/rt/+freebsd/types.ha +++ b/rt/+freebsd/types.ha @@ -53,7 +53,7 @@ export def SIG_UNBLOCK: int = 2; export def SIG_SETMASK: int = 3; export type sigval = union { [message trimmed]
From Sebastian to ~sircmpwn/hare-dev
Signed-off-by: Sebastian <sebastian@sebsite.pw> --- hare/parse/doc/doc.ha | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/hare/parse/doc/doc.ha b/hare/parse/doc/doc.ha index f7c4a129..5062414a 100644 --- a/hare/parse/doc/doc.ha +++ b/hare/parse/doc/doc.ha @@ -42,7 +42,8 @@ export fn parse(in: io::handle, start: lex::location) (doc | error) = { let sc = bufio::newscanner(in); defer bufio::finish(&sc); match (_parse(&sc)) { [message trimmed]