On Thu Dec 1, 2022 at 8:39 PM CET, Armin Weigl wrote:
> On Sun Nov 20, 2022 at 4:21 PM CET, Bor Grošelj Simić wrote:
> > Does this have anything to do with the rest of the commit?
> Added these to reproduce a bug in an earlier version of this patch, can
> leave them out if desired.

We should keep them unless they don't make sense anymore after this patch got
changed, but you should either make it clear in the commit message why they are
relevant to this commit, or put them into a separate commit and document their
meaning there.

On Thu Nov 24, 2022 at 4:17 PM CET, Pierre Curto wrote:
> Makes sense. Making the change in check.c (check_expr_binarithm)
> breaks existing code
> in a few places where the right hand side is a simple int though,
> e.g. https://git.sr.ht/~sircmpwn/harec/tree/master/item/rt/%2Blinux/syscalls.ha#L44
>
> I have double checked the specifications and it does mention that both
> operands must be
> unsigned. OK to fix the places where this breaks?

Yes, though probably with a notice on hare-users when it gets merged.

Rejecting this approach, see https://todo.sr.ht/~sircmpwn/hare/771#event-215318
for explanation.

This is not the correct fix for #769:

>  		if (new->otype == O_SCAN) {
>  			new = wrap_resolver(ctx, new, resolve_enum_field);
This line says, hey, tell me what this enum field really is, by doing some
calculations in local enum scope.

> -		assert(new->otype == O_CONST);
The intent of this assert is to verify that whatever the previous call
returned is actually an enum field (it does so in a very dumb way that should
be changed, but that's not relevant here). The reason this assert is triggered
by ordinary declarations is that at some stage before this line scoping, isn't
set up correctly by the compiler and the the call to `wrap_resolver` sometimes
grabs the wrong (global, instead of enum-local) object with a certain

> +		if (subtype != from) {
> +			subtype = type_dealias(subtype);
> +		}
>  		assert(subtype == from); // Lowered by check

Such failing gen asserts usually need to be fixed somewhere else.

This particular issue and #725 both hint at some flaw in tagged_select_subtype.

If I'm correct, the fix should be there, so that all callers of
tagged_select_subtype will benefit from it.

Thanks!

To git@git.sr.ht:~sircmpwn/hare
   b51e0a6c..14d4abd2  master -> master

> +	case => free(TZ_LOCAL.zones);

Style: nontrivial expressions should be on a separate line in match cases

This was written 2 months ago but was never sent for some reason:

> Hi,
>
> Thanks for your work. I think your patch is getting close to
> being merge-able in master so that folks can try it out and
> provide feedback. I will work on that after the thread-local
> storage patches from Drew.
>
> I'm not too keen on the syntax 'file' at toplevel does not
> really look like debug. Same applies to the 'loc' operation.

The names are taken directly from gas, because the functionality is taken
directly from gas too - .file maps a file id to filename and .loc specifies the

Thanks!

To git@git.sr.ht:~sircmpwn/hare
   2f275891..b51e0a6c  master -> master

Thanks!

To git@git.sr.ht:~sircmpwn/harec
   fe734cf..2623740  master -> master