P.S. Sorry for sending to the wrong list. I'll use your public inbox for future mails.

From: Rosie Keith Languet <rkl@rosiesworkshop.net>

s/migw32/mingw32/
---
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.md b/README.md
index f965fa13..5fef412a 100644
--- a/README.md
+++ b/README.md
@@ -62,7 +62,7 @@ You need the following:
 
 To build with EFI support:
[message trimmed]

Thanks for taking a look at this Drew, although I know it's now been a
while. I'm bumping this thread now, in part, because ~spxtr has been
asking about conformance tests on IRC.

>> https://git.sr.ht/~roselandgoose/hare2c2/tree/44823c1d9e3dc7f3c5749b60e9f571014f71f99d/item/hare/check

(link updated to reflect the status of the code at the time)

>> I've got an error type with an identifying enum that is (hopefully) very
>> easy to add to (with a code-gen'd errcode_tostr function to get the doc
>> comment for each enum value).
>
>> I figure a test which asserts that the resulting error is (or contains)
>> an error with a given enum value, that was initialized by a particular

Also Hi! I offer a small addition to Lorenz's comments, for you and for 
future hare learners.

> the right move here would be to just work with the memio::stream
> directly instead of taking a pointer to it :)

Indeed this is the more common pattern across the ecosystem. Alternatively,
you could also alloc() the stream and free() it after closing it.

With Lorenz's suggestion the stream is copied from foo's stack to main's.
Since the stream will not out-live main, you can safely take its address
there and use it as you had:

```

Signed-off-by: Rosie Keith Languet <rkl@rosiesworkshop.net>
---
 README.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/README.md b/README.md
index a2cb97a..ed89d58 100644
--- a/README.md
+++ b/README.md
@@ -83,6 +83,7 @@ If you're interested specifically in 3D graphics, check out
 
 * [~yerinalexey/afl_harec](https://git.sr.ht/~yerinalexey/afl_harec): Hare instrumentation for [AFL](https://github.com/google/AFL)
 * [~yerinalexey/hare-annotate](https://git.sr.ht/~yerinalexey/hare-annotate): A library for implementing code generators
+* [`~roselandgoose/gen_enum_strs`](https://git.sr.ht/~roselandgoose/hare2c2/tree/main/item/cmd/gen_enum_strs): A Hare `fn $enum_to_str($enum) str` code generator
[message trimmed]

Im very excited to see this proposal!

> For example, it is often necessary to statically allocate
> variables whose initializers cannot be evaluated at compile-time,

Another case where ^this^ has been true for me is when initializing
global unstable (exported but undocumented) structs. I recently wrote
the following to interface with debug:: and debug::image:


```
def self: *image::image = &self_buf: *image::image;

let self_buf: [size(image::image)]u8 = [0...];

Hi Bor,

>> One thing bootstrap harec does somewhat well is making sure invalid code is
>> actually rejected - we have an established way of doing that and we're also
>> strict about requiring those tests during code review. There is however no way
>> to track which error is associated with which test, and that means tests
>> frequently get outdated and irrelevant. Solving this will require some
>> thinking.

> I have some thoughts on how to achieve this... Hopefully today I'll have
> time to flesh them out here:
> https://git.sr.ht/~roselandgoose/hare2c2/tree/main/item/hare/check/errors.ha
Well I ran out of time last week, but I have now prototyped some
riggings. Let me know what sort of cases the following would be

Thanks Bor & Drew!

> In hosted checker [calling compiler's internal functions directly from
> the tests] should be much easier fortunately. Having a lot of unit tests is imo
> more important than importing the old tests and slowly making them pass one by
> one.
I think you're right. You've convinced me to build up the (intrusive)
unit tests alongside the typechecker.

> One thing bootstrap harec does somewhat well is making sure invalid code is
> actually rejected - we have an established way of doing that and we're also
> strict about requiring those tests during code review. There is however no way
> to track which error is associated with which test, and that means tests
> frequently get outdated and irrelevant. Solving this will require some

Hi all,

I can't seem to find it now, but I believe Drew has previously mentioned
intentions to re-work the harec test suite into something more general.
I am planning on starting a fresh write of the hosted typechecker and I
would like to start by creating a test suite of sorts.

For my initial hacking I had thrown together this little driver [1], but
I think something a _little_ bit more sophisticated (and a lot less
slapped-together) would be wise.

[1]: https://git.sr.ht/~roselandgoose/test_hare_unit

Any thoughts or suggestions?

Thanks Ember!

> flexible type hashes are just based on the storage/flags (this is where
> the distinguishing between the variants happens) along with a unique id
> that's incremented each time a new flexible literal type is created.
Ah I see. It's just that last part that's missing from hare::types::hash

I see the relevant switch case(s) in harec:src/types.c:type_hash() which
is missing, as well as the harec:include/types.h:type_const struct that
it depends on. (I last pulled before the s/const/literal/ spec changes -
these types may have changed names since but ¯\_(ツ)_/¯ )

> this hash can never make it into the abi, so the only requirement is
> that each call to type_create_flexible creates a type with a unique