ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
steveno_ has joined #zig
cenomla has joined #zig
hopppetosse has quit [Ping timeout: 265 seconds]
Hejsil has quit [Read error: Connection reset by peer]
tridactyla has quit [Remote host closed the connection]
<GitHub37>
zig/master 152b408 Andrea Orru: Simplify intrusive linked list test
<aiwakura>
^ yes
jfo has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
jfo has quit [Ping timeout: 240 seconds]
zigzag has quit [Ping timeout: 260 seconds]
isd has quit [Ping timeout: 264 seconds]
isd has joined #zig
jfo has joined #zig
jfo has quit [Ping timeout: 256 seconds]
<MajorLag>
andrewrk, think I found a compiler bug that isn't comptime or involving pointers for a change. I have a function that returns `!?[]const u8`, the only condition within it under which an error is thrown is a `try` statement. Compiler tells me I have to return at least one possible error.
<MajorLag>
If I take `!` out of the type, it complains that it expected `?[]const u8` but found an errorset.
<GitHub108>
[zig] AndreaOrru pushed 1 new commit to master: https://git.io/vAjMo
<GitHub108>
zig/master 10fb1f2 Andrea Orru: Merge branch 'test-ci'
<MajorLag>
I think the actual problem is in parsing the return type. if I change it to `error!?[]const u8` it seems happy with it
aiwakura has quit [Quit: ...]
jfo has joined #zig
tiehuis has joined #zig
<tiehuis>
brought the freebsd branch back up to date, hello world compiling and running again
aiwakura has joined #zig
jfo has quit [Ping timeout: 276 seconds]
tiehuis has quit [Quit: WeeChat 2.0.1]
monteslu has quit [Ping timeout: 240 seconds]
monteslu has joined #zig
tiehuis has joined #zig
<MajorLag>
ugh, freaking comptime. iterator works perfectly fine at runtime, infinite loops if it is called at comptime.
<MajorLag>
from what I can tell, the compiler runs the next() function exactly once, then caches the value for every iteration of the loop.
<MajorLag>
this took a while to track down, because the orignal error being reported was `cannot asign to const`, which occurs when it overruns the comptime buffer it is writing to.