02:25 <mpiannucci> Hey has anyone managed to cross compile for iOS? I have been working through by trying to fix compiler issues as I go, but wanted to see if anyone else has any tips or has attempted it.

02:46 <scientes> just like that Duch...gone

03:12 <ibebrett> can anyone give me some insight on whats wrong with:

03:12 <ibebrett> fn formatDigit(byte: u8) u8 { return switch(byte) { u8(0) => '0', else => 'x' }; }

03:12 <ibebrett> i keep getting: error: unable to infer expression type

03:13 <ibebrett> This does compile: fn formatDigit(byte: u8) u8 { return switch(byte) { else => 'x' }; }

05:53 <ibebrett> is there an issue using the c allocator within a test

06:06 <ibebrett> i think it was just that i didn't add the c library as a dependency for the test step, the error message was something about there being two _start symbols though

06:06 <ibebrett> is it possible that linking c changes the zig compilers entry point?

06:07 <scientes> ibebrett, yes, if you link with libc you need a int main

06:07 <scientes> but otherwise zig provides a _start

06:07 <ibebrett> so i think the "test" step

06:08 <scientes> (at x80 on x86)

06:08 <ibebrett> maybe it could be a nicer error message

06:08 <ibebrett> for linking the builder "test" stuff

06:08 <ibebrett> instead of ilke "undefined symbole malloc"

06:08 <ibebrett> i got two _starts

06:08 <scientes> yeah you should report that as bug

06:09 <scientes> tests generally use the test allocator

06:09 <ibebrett> ah

06:09 <scientes> but tests really should support libc linking too

06:09 <ibebrett> that also, would have been good to know lol

06:09 <ibebrett> but yeah, ill report it anyway

06:10 <scientes> yeah you have to read code to get documentation of stuff not part of the language

06:10 <scientes> actually tests _are_ part of the language....but still kinda undefined

06:10 <scientes> *undocumented

06:11 <scientes> see https://github.com/ziglang/zig/issues/480 for discussions about allocators

06:12 <scientes> yeah you want the debug allocator

06:12 <scientes> which is just a static single allocation of memory

06:12 <scientes> very simple

06:13 <ibebrett> https://github.com/ziglang/zig/issues/1824

06:14 <scientes> Oh, so it works if you link to libc?

06:14 <ibebrett> yeah

06:16 <scientes> oh

18:19 <ibebrett> got an error: ../zig/build/bin/zig build test zig: /home/brett/w/zig/src/ir.cpp:18694: IrInstruction* ir_analyze_instruction_slice(IrAnalyze*, IrInstructionSlice*): Assertion `ptr_type->id == ZigTypeIdPointer' failed. The following command terminated unexpectedly:

18:19 <ibebrett> this to me seems like a bug?

20:23 <unique_id> ibebrett: Yep, that's a bug. As I understand it, not all of these kinds of bugs will be fixed in the current compiler. Rare edge cases that don't matter will be fixed in the self hosted compiler (written in Zig). The current compiler will later be used just to compile the self hosted one. You can file a bug report and it'll either get fixed or at minimum be used as a test case for the self hosted compiler.

20:24 <unique_id> I used to come across a fair bit of these assertions, now I don't.

20:26 <unique_id> Of course if it's code that should compiler, that's a different story

20:27 <unique_id> compile*