~turminal

Ljubljana, Slovenia


#938 lower_implicit_cast performs casts that are not otherwise allowed by the spec a month ago

Comment by ~turminal on ~sircmpwn/hare

The spec doesn't have a concept of "implicit casts"; it only has castability and assignability. There's been some talk about making a distinction between assignment and implicit casts, but as Hare currently stands, implicit casts are just an implementation detail.

Yeah I know implicit casts are just an internal harec thing. I don't think they need to be a distinct concept, in fact, I think they're linked more closely than it looks like if one doesn't read the code carefully enough. Out of 24 uses of type_is_assignable in check.c, 20 of them are immediately followed by a call to lower_implicit_cast. Out of all the uses of lower_implicit_cast, most of the ones that are not preceded by an assignability check are either subtly wrong, unneeded, or the assignability is implicitly established in the code by other means.

Again, I realize this is all just implementation details and has no factual relevance to the abstract language as defined by the spec, but looking at how implementation has developed organically, can be a very good heuristic.

The current intent is that assignability rules are a subset of castability rules, with the exception that never can be assigned to any type, but not casted.

+1

So the assignment from alloc to []int doesn't depend on castability rules at all. I don't think alloc needs any special casing here (within either harec or the spec), sans issues with type hints (which is a separate thing). I also don't think the spec needs any updating, besides adding the missing array pointer -> slice castability rule. Making harec's code nicer and more maintainable is definitely good, but I don't think this is a correctness issue;

The remark about alloc special casing was made based on a couple of incorrect assumptions, all originating from the fact that I was not aware *[3]int -> []int is a valid assignment. I agree now that no special casing is needed. This ticket was only meant to track issues with internal handling of implicit casts, I never meant to imply there's anything wrong with the spec (aside from that missing castability rule).

I'm not aware of any instances where harec's rules for assignability/castability don't match those of the spec. Do you know of any?

Assigning to void is not allowed from an arbitrary type in harec, but is supposed to be allowed from any type according to the spec. Same for done. I can't remember anything else right now, but I'm sure there are things I've seen relatively recently that don't behave well.

#938 lower_implicit_cast performs casts that are not otherwise allowed by the spec a month ago

Comment by ~turminal on ~sircmpwn/hare

The issue is that the spec doesn't allow casts from array pointers to slices. I overlooked the fact that it allows assignments, so I guess this is also a spec issue? I'm not sure.

The point is that there should be rules for what lower_implicit_cast can and cannot do (checked with a bunch of asserts probably), because right now anything can be passed in and it's up to gen to decide whether it is to be compiled or not, and gen has support for some stuff that shouldn't be there according to the spec.

#938 lower_implicit_cast performs casts that are not otherwise allowed by the spec a month ago

harec added by ~turminal on ~sircmpwn/hare

#938 lower_implicit_cast performs casts that are not otherwise allowed by the spec a month ago

Ticket created by ~turminal on ~sircmpwn/hare

For example, let a: []int = alloc([1,2,3]); is compiled with a *[3]int -> []int implicit cast.

I guess it makes sense that this cast is not allowed, but then harec needs to handle special cases around alloc with dedicated code, not by abusing the cast mechanism. The gen code that enables this should also be (re)moved.

#889 Improve slice/array type representation in the compiler a month ago

Comment by ~turminal on ~sircmpwn/hare

Bor Grošelj Simić referenced this ticket in commit c0db5b1.

#889 Improve slice/array type representation in the compiler a month ago

Comment by ~turminal on ~sircmpwn/hare

Bor Grošelj Simić referenced this ticket in commit 42573fc.

#936 HAREPATH shadowing of modules with assembly symbols does not work a month ago

driver added by ~turminal on ~sircmpwn/hare

#936 HAREPATH shadowing of modules with assembly symbols does not work a month ago

bug added by ~turminal on ~sircmpwn/hare

#936 HAREPATH shadowing of modules with assembly symbols does not work a month ago

Ticket created by ~turminal on ~sircmpwn/hare

With the cache populated by the stdlib, cd-ing to the harec repo and attempting to build (with -R, to avoid further breakage from trying to pull in additional modules) a module with a single empty function, I get:

(.text+0x0): multiple definition of _start'; /home/bor/.cache/hare/home/bor/src/hare/harec/rt/6fbb542519dc7c019449a0195799a08d4edad83f8a08fb433d625f5e13fe4133.o:(.text+0x0): first defined here

and a bunch of other similar ones for syscall[0-6].

I don't understand the build driver very well, but what I expect it to do is figure out the rt module that it's attempting to pull in (the one from harec) is different than the rt module it has in the cache (from the stdlib), and to ignore the stdlib one completely.

#88 Allow type and constant declarations in function bodies a month ago

easy removed by ~turminal on ~sircmpwn/hare