ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
jsb has quit [Quit: .]
jsb has joined #zig
notzmv- has joined #zig
notzmv- has quit [Remote host closed the connection]
notzmv has joined #zig
notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
notzmv has quit [Ping timeout: 240 seconds]
ur5us_ has joined #zig
brzg has joined #zig
fputs has joined #zig
cole-h has quit [Ping timeout: 240 seconds]
daurnimator has joined #zig
remby has left #zig ["Good Bye"]
gazler_ has joined #zig
gazler__ has quit [Ping timeout: 260 seconds]
dimenus has joined #zig
<andrewrk> ifreund, it's really nice that your distinct type patch also made the ZIR printing show the @ names
<andrewrk> in retrospect it seems obvious that Ref should have been an enum :)
<sh4rm4^bnc_> andrewrk, the x86_64-windows-gnu zig-cc target is cygwin ?
<andrewrk> sh4rm4^bnc_, the libc that it provides is based on mingw-w64
<andrewrk> however it is ABI compatible with MSVC (but not always .h file compatible)
<sh4rm4^bnc_> based on, means it's like an improved fork of ?
<g-w1> with the std.zig.ast api, how can I get the length of a token? I want tree.source[tree.firstToken(node) .. tree.lastToken(node) + len] to get the full source of a node. is this possible?
<sh4rm4^bnc_> because last time i checkout mingw-w64 it was utterly broken...
<sh4rm4^bnc_> like declaring int mkdir(char*)
<g-w1> ah figured out, just use the last token, but + 1 so its the start of the next token
<andrewrk> sh4rm4^bnc_, does this look problematic?
<sh4rm4^bnc_> yeah, that looks like what my mkdir-using program choked on
<sh4rm4^bnc_> it lacks the mode parameter
<noam> Since stage2 doesn't yet support this so I can't steal^W*take inspiration* from it regarding field allocation: does it make sense to treat each field as its own variable in terms of e.g. regalloc?
<andrewrk> sh4rm4^bnc_, it looks deprecated, are you sure it's ok to call it?
<sh4rm4^bnc_> man 3p mkdir says nothing about deprecated (posix 2013 manpages)
<andrewrk> g-w1, have a look at ast.Tree.tokenSlice if you haven't seen it yet
<g-w1> thats only for one token, I want a whole node, but I figured it out
<andrewrk> oh I see you want a whole node
<g-w1> i just did lastToken + 1
<andrewrk> that works because we terminate with an EOF so you can always do +1 from a non-EOF token
<g-w1> ok cool
<andrewrk> you might get unwanted line comments tho
<g-w1> its mostly for fields of structs and global variables
<waleee-cl> sh4rm4^bnc_: file modes doesn't exist on windows? Or have I missed something
<andrewrk> sh4rm4^bnc_, might be worth having a chat with the #mingw-w64 folks (on OFTC). they might have a good reason for the way it is
marler8997 has joined #zig
<sh4rm4^bnc_> waleee-cl, i dunno, but mingw is supposed to provide a posix compat layer
<andrewrk> also I haven't double checked that msvc libc does it differently, have you?
brzg has quit [Quit: leaving]
<sh4rm4^bnc_> i just tried to compile my posix compatible program with mingw, and found it wasnt compatible at all
<sh4rm4^bnc_> it == mingw
<andrewrk> mingw is not a posix compatibility layer
<andrewrk> it's trying to match msvc
Miaourt has quit [Quit: Ping timeout (120 seconds)]
<andrewrk> put an #ifdef windows in your code
Miaourt has joined #zig
<andrewrk> IMO posix compatibility layer is misguided. better to have conditional compilation and use appropriate windows APIs on windows
<daurnimator> as andrewrk said, mingw is not meant to be posix compatible...
<daurnimator> IIRC they only added enough posix to get autoconf to work out of the box
<sh4rm4^bnc_> lol
<daurnimator> andrewrk: mingw isn't trying to match MSVC directly, IIRC they add plenty more on top
<andrewrk> anyway it's a completely reasonable libc, and I agree with the decision to not try to be a posix compatibility layer
<sh4rm4^bnc_> alright, i was just curious whether the version used by zig is somehow improved or uses midipix, or cygwin, or whatever
sm2n_ has joined #zig
sm2n has quit [Ping timeout: 252 seconds]
<andrewrk> zig's is unpatched mingw-w64
<sh4rm4^bnc_> unrelated: i recently found and i immediately figured this would make like a perfect multi-arch backend for a compiler (was thinking about cproc)
<sh4rm4^bnc_> what's the backend approach for the new llvm-less zig compiler ?
<andrewrk> hard work
<sh4rm4^bnc_> you write asm for every arch yourself ?
<andrewrk> yes, direct to machine code for every arch ourselves (no detour through assembly syntax)
<g-w1> not asm: code
<sh4rm4^bnc_> lightning supports about 12 archs, almost all that musl supports (except sh2-4)
<andrewrk> we're not gonna take on more dependencies, llvm is troublesome enough
<sh4rm4^bnc_> input is a risc pseudo asm, and it's pretty lightweight
<sh4rm4^bnc_> well yeah, since you're already half-way there :)
<andrewrk> it's fast too
<andrewrk> compilation speed
<sh4rm4^bnc_> *nod*
<sh4rm4^bnc_> how about optimization of the code ?
<andrewrk> roughly equivalent to gcc or clang -O0
<sh4rm4^bnc_> i.e. zero
<sh4rm4^bnc_> according to the most important optimization is register allocation
<sh4rm4^bnc_> (lightning does that too)
<andrewrk> oh we're doing that
<andrewrk> single pass register allocation
<sh4rm4^bnc_> ah cool, so it should be faster than gcc -O0
<andrewrk> there is a liveness analysis too so it can re-use dead registers
<andrewrk> that is surprising to me. I thought the cpu cache would make register allocation not very important
<sh4rm4^bnc_> the guy who wrote that article is vladimir makarov, who does the really hard work on GCC, he also wrote a scripting lang called dino that's a lot faster than even lua
<sh4rm4^bnc_> ( Implementation of the Programming Language Dino – A Case Study in Dynamic Language Performance )
<companion_cube> that almost looks like a nice language, damn
<mikdusan> dang that pdf is filled with goodies
ifreund has quit [Ping timeout: 265 seconds]
ifreund has joined #zig
jicksaw has quit [Quit: ZNC is kill]
jicksaw has joined #zig
<andrewrk> 3.1 Byte Code Dispatch is related to
paulgrmn has quit [Ping timeout: 248 seconds]
fireglow has quit [Quit: Gnothi seauton; Veritas vos liberabit]
<mikdusan> if I grok correct, dino switched to "direct threaded code" (labels as values) because > 256 instructions
<andrewrk> right now in stage2 we got < 256 instructions, and already have that proper switch setup, so looks like we can just sit tight
<andrewrk> that's what I was showing off in the meeting today
osa1_ has joined #zig
osa1 has quit [Ping timeout: 248 seconds]
fireglow has joined #zig
bitmapper has quit [Quit: Connection closed for inactivity]
forgot-password has quit [Ping timeout: 245 seconds]
xackus_ has joined #zig
xackus has quit [Ping timeout: 276 seconds]
notzmv has joined #zig
wootehfoot has quit [Quit: Leaving]
adsr has joined #zig
earnestly has quit [Ping timeout: 258 seconds]
nycex has quit [Remote host closed the connection]
nycex has joined #zig
<andrewrk> g-w1, check it out, the stage2 test case for compile logs had the wrong source location in master branch but with this branch now it's fixed (see latest commit, the changes to the test case)
<g-w1> i saw that :)
<g-w1> oh even more?
<andrewrk> yeah I don't think we noticed this one before but the source location was bogus
<g-w1> nice
<g-w1> i think my next thing will be @intToError and @errorToInt, because those require some special casing in the cbe that will cause subtle bugs. those are safe to work on with lazy analysis right?
Biolunar has quit [Ping timeout: 240 seconds]
Biolunar has joined #zig
<andrewrk> g-w1, what about this strategy? have `#define zig_error_int_<name> <number>` for every error, and the C backend simply populates this on flush()
<andrewrk> so every incremental compilation it would have to write the whole list of error names / numbers with #defines, but it means the other code could stay unmodified even if error numbers get changed
squeek502 has joined #zig
sm2n_ is now known as sm2n
<andrewrk> some fun code I just added to rvalue for the `ty` enum value:
<andrewrk> lines 27 to 89
Rum has joined #zig
ur5us_ has quit [Ping timeout: 258 seconds]
zie has quit [Quit: ZNC 1.8.1 -]
terinjokes has quit [Quit: ZNC 1.8.1 -]
terinjokes has joined #zig
Rum has quit [Remote host closed the connection]
Rum has joined #zig
dimenus has quit [Ping timeout: 252 seconds]
Xe is now known as Cadey
waleee-cl has quit [Quit: Connection closed for inactivity]
tefter has quit [Quit: WeeChat 3.1]
zuyoutoki has joined #zig
cole-h has joined #zig
leon-p has joined #zig
zuyoutoki has quit [Ping timeout: 240 seconds]
RadekCh has joined #zig
frett27 has joined #zig
tnorth_ has joined #zig
sord937 has joined #zig
Rum has quit [Quit: Leaving]
l1x has quit [Ping timeout: 240 seconds]
dputtick has quit [Ping timeout: 258 seconds]
l1x has joined #zig
dputtick has joined #zig
earnestly has joined #zig
yyp has joined #zig
osa1_ is now known as osa1
lemmi has joined #zig
frett27 has quit [Ping timeout: 240 seconds]
sord937 has quit [Remote host closed the connection]
sord937 has joined #zig
notzmv has quit [Read error: Connection reset by peer]
sundbp has joined #zig
ksynwa has left #zig [#zig]
semarie has joined #zig
dyeplexer has joined #zig
cole-h has quit [Ping timeout: 240 seconds]
<ifreund> andrewrk: yeah, it really did turn out to be a strict improvement in the end I think :)
<ifreund> andrewrk: I thought slices don't have a well defined memory layout, is @bitCast([]Inst.Ref, raw_slice) really safe?
<ifreund> I think a pointer cast would be more correct
notzmv has joined #zig
<ifreund> I'm working on astgen for slicing by the way
WilhelmVonWeiner has joined #zig
forgot-password has joined #zig
RadekCh has quit [Quit: Connection closed]
tadzik has joined #zig
<tadzik> hello #zig!
<tadzik> I've tried building on Linux, using zig 0.7.1. The `zig build` fails with `ld.lld: error: unable to find library -lglfw` (same for epoxy)`. The libraries are present in my system, and my C programs linking with glfw compile and run just fine. How can I investigate what I'm missing?
<g-w1> andrewrk │ [23:53:04] g-w1, what about this strategy? have `#define zig_error_int_<name> <number>` for every error, and the C backend simply populates this on flush() andrewrk: see there is a subtle off by one error if you are not careful
dyeplexer has quit [Ping timeout: 260 seconds]
<cepheus> tadzik: I have toy examples that work successfully against GLFW in my case, but i'm linking against GLFW3 in my case
<cepheus> can't comment on epoxy though
<tadzik> cepheus: yeah, it's glfw3 for me too, but for the linker it seems to be -glfw anyway
<cepheus> if you specifically do GLFW3 i think it should be able to find it via pkg-config which resolve the issues (if that's set up correctly)
<tadzik> I'm not sure if epoxy is relevant here, it just seems like my zig can't quite link to the C stuff that clang does just fine
<cepheus> (it's case sensitive I think)
<tadzik> pkg-config --libs glfw3 gives me -lglfw as expected
<cepheus> hmm
<cepheus> I'm also building these under nix which is probably not representative of the typical case
<tadzik> possibly
<cepheus> I'll see how this builds under my env just to check
<tadzik> I could try linking something more trivial in a more minimal case, like `-lm` for cmath, if I knew how to write and build any zig myself :P But I thought I'd start by looking at comparing's someone's Zig and comparing it to my C
<tadzik> ugh, english had. s/comparing's//
<cepheus> yeah it's weird
<cepheus> asides changing that glfw to glfw3 for my system it works fine and runs on my system
<cepheus> sorry that's not very helpful
<tadzik> no worries, thanks anyway :)
<tadzik> interestingly (or maybe not), even if I change glfw to glfw3 in build.zig, it still tries to link against -lglfw
Snaffu has joined #zig
zuyoutoki has joined #zig
WilhelmVonWeiner has quit [Quit: leaving]
WilhelmVonWeiner has joined #zig
zuyoutok1 has joined #zig
<v0idify> tadzik, that's because it's just the pkg-config name
<v0idify> andrew uses nix so it should work
zuyoutok1 has left #zig [#zig]
<tadzik> nodnod
v0idify has quit [Ping timeout: 240 seconds]
v0idify has joined #zig
euantorano has joined #zig
stromberg has joined #zig
<gracefu> what's the status on safe recursion? issue 1006 says the accepted proposal is to use async calls, but isn't async already a thing? why is issue 1006 still open?
WilhelmVonWeiner has quit [Quit: leaving]
wootehfoot has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
paulgrmn has joined #zig
wootehfoot has joined #zig
dimenus has joined #zig
<ifreund> gracefu: the compiler doesn't enforce following that pattern yet
<gracefu> why not?
<ifreund> and for good reason IMO, async in zig is very much still at the PoC stage
<gracefu> ah
<gracefu> because async still in dev
<gracefu> right
<gracefu> so when async is polished up and ready to ship, so will safe recursion?
<ifreund> I assume so yes
<gracefu> makes sense
<gracefu> thanks!
Rum has joined #zig
yyp has quit [Ping timeout: 240 seconds]
yyp has joined #zig
sord937 has quit [Ping timeout: 240 seconds]
Rum has quit [Quit: Leaving]
sord937 has joined #zig
Snaffu has quit [Quit: leaving]
grive has quit [Quit: Bye]
grive has joined #zig
<ifreund> andrewrk: we might want to consider using non-exhaustive enums for Type and Value as well, could be cleaner
<g-w1> how could it be cleaner?
<ifreund> you replace the extern union { usize, *Payload } + separate Tag enum with a single enum(usize) {}
<ifreund> looking closer it wouldn't acutally work in this case though as there are tags that have a payload as well
<g-w1> yeah
<ifreund> well, no it would work fine but wouldn't necessarily be cleaner
yyp has quit [Quit: now it's safe to turn off your computer]
Wolf480pl has quit [Quit: ZNC disconnected]
Wolf480pl has joined #zig
Yardanico has quit [Remote host closed the connection]
stromberg has quit [Quit: Connection closed]
jmiven has quit [Ping timeout: 240 seconds]
Yardanico has joined #zig
jmiven has joined #zig
marijnfs has quit [Ping timeout: 252 seconds]
xackus_ has quit [Ping timeout: 246 seconds]
marijnfs has joined #zig
xackus_ has joined #zig
frett27 has joined #zig
notzmv has quit [Ping timeout: 240 seconds]
tnorth_ has quit [Ping timeout: 245 seconds]
<caolanm> how do I ignore SIGPIPE in a zig program?
<ifreund> caolanm: same way as in C, man sigprocmask
<caolanm> at the moment I'm linking lib C to do it using signal()
<ifreund> signal() is deprecated iirc
<caolanm> yes, I think you're right
<caolanm> I was just being lazy to get it working
<ifreund> or it's at least recommended to use sigprocmask
<caolanm> I couldn't get my head around using sigprocmask from zig
<caolanm> and theres no definition for things like SIGPIPE
<caolanm> I mean, I could hard code it to 13 but...
<ifreund> std.os.SIGPIPE
<caolanm> hmm, don't see that in docs or sourcecode
forgot-password has quit [Ping timeout: 276 seconds]
<caolanm> does some magic happen to define that?
<g-w1> usingnamespace on bits
<ifreund> if you're talking about the autogenerated stdlib docs, I recommend avoiding them as they are very incomplete and sometimes incorrect
<ifreund> if you grep for SIGPIPE you'll find the definitions
<ifreund> keep in mind that the std is in for a good restructuring before 1.0, current focus is on the compiler
<caolanm> yeah, that's ok - I'm just playing :)
<caolanm> it's been difficult without stdlib docs, but the language itself is nice to beginners
<g-w1> i reccomend reading the source code itself
<caolanm> I've been using github search on the zig repo
<ifreund> zls has goto-definition which makse that nicer by the way
<caolanm> might just clone it so I can grep more easily
<ifreund> the std source also ships with your copy of zig
<caolanm> ah, cool
<ifreund> zig env
<ifreund> (to find the path)
<caolanm> making a little HTTP/1.0 server for my own amusement - only handles GET requests :)
<ifreund> nice :)
<caolanm> cool, thanks. I hadn't seen hzzp
<caolanm> I don't even parse headers
<ifreund> :D
<caolanm> just read a path, write the file, close connection
<caolanm> :)
<caolanm> hmm
<caolanm> ./src/main.zig:17:11: error: container 'std.os' has no member called 'sigaddset'
<caolanm> but I see it in stdlib in os/linux.zig
<ifreund> std.os.system.sigaddset
<ifreund> std.os.system is an alias for whatever your current target system is, which in this case is linux
<ifreund> you can also just do std.os.linux of course
<caolanm> ./src/main.zig:17:18: error: container 'std.c' has no member called 'sigaddset'
<caolanm> std.os.system.sigaddset(&set, std.os.SIGPIPE);
<ifreund> oh you're linking libc
<ifreund> in that cse std.os.system is std.c
<caolanm> ah, but! I was only linking libC so I could use signal()
<caolanm> let me turn that off
cole-h has joined #zig
<caolanm> all working now btw, thanks
mschwaig1 has quit [Quit: WeeChat 3.0]
<ifreund> no problem!
yyp has joined #zig
detha has quit [Quit: ZNC -]
detha has joined #zig
notzmv has joined #zig
Akuli has joined #zig
<andrewrk> ifreund, I think we actually uncovered a design flaw here - a pointer cast will assert the pointer is not 0, but in the case of a slice with .ptr = undefined, len = 0, this will trip. but we don't want a pointless len check
<andrewrk> so my reasoning here is (and I apologize for not putting this in a comment) this bitcast does generate correct llvm code with stage1, and as the language finalizes it either needs to keep being a valid construct or start being a compile error, so we should be ok until either of those things happen
<andrewrk> does that make sense? (regarding the ptr cast / bitcast on slice)
<ifreund> andrewrk: sounds reasonable, I'd vote to make @ptrCast() work on slices and do the right thing
<ifreund> (from a language design standpoint)
<ifreund> or well, I guess we can implement that in userland no?
<andrewrk> ifreund, I think that's exactly the right call, make @ptrCast work on slices
<ifreund> yeah, my userland version still has the length check
<andrewrk> that len == 0 check is unfortunate though, we really want the codegen to just reinterpret a pointer at the end of th eday
<andrewrk> I don't see any downsides from making @ptrCast work on slices
<ifreund> yeah me neither.
<andrewrk> I'm not sure if Type and Value are the right way to go
<andrewrk> but don't want to mess with them until there is a clear vision for why something else is better
<andrewrk> I think that may happen when we implement comptime locals
<ifreund> makes sense, it was mostly just an idle thought after looking at them breifly while implementing float literal astgen
<g-w1> andrewrk: do you understand why errorToInt and intToError might cause subtle bugs in the cbe? or am I missing something?
<andrewrk> g-w1, hard to say without some more details
<g-w1> there is a subtle off by one error if you are not careful. I linked this earlier but not sure if you saw
<andrewrk> hmm I don't understand the problem
<g-w1> ill link the code
<andrewrk> integer value 0 is reserved, the first error.Foo starts at 1
<g-w1> yeah, but then the errors are different at comptime and non-comptime
<g-w1> comptime is 0, non-compitme is 1
<g-w1> so we have to account for that
<andrewrk> I don't follow
<g-w1> comptime @errorToInt(e) -> 0 (stored in module), runtime @errorToInt(e) -> 0, but now it is off because 0 is the value for no error so we get ub
<g-w1> so we have to add 1 if its runtime in the cbe right?
<andrewrk> you can never get 0 from @errorToInt on an error set type
<g-w1> hmm, why?
<andrewrk> because 0 is reserved for "not an error"
<g-w1> is there docs for that?
<ifreund> each error name across the entire compilation gets assigned an unsigned integer greater than 0
<ifreund> (from the langref)
<g-w1> ohhhh thanks
<g-w1> sorry for the invoncvience
<andrewrk> no prob
<andrewrk> did that answer the question? because I'm still confused
<g-w1> it answered it. then there is a small cbe bug that i introduced :(. I will fix it when I do errorToInt and intToError
<andrewrk> ahh ok no worries
<g-w1> there should be no +1 there right?
<andrewrk> yeah probably global_error_set should have the u16 value match exactly right? so there will be no 0 value in global_error_set
<g-w1> yeah
<g-w1> that confused me, not sure if it starts at 1 or 0
<andrewrk> we just skip 0 so that you can convert from an error set type to an error union type with a no-op
<g-w1> yeah
<g-w1> ok cool, thanks
<andrewrk> in machine code, anyerror!void is represented the same as anyerror
fputs has quit [Quit: WeeChat 3.1]
leon-p has quit [Quit: leaving]
semarie has quit [Quit: WeeChat 3.0.1]
semarie has joined #zig
<g-w1> is the only way to store an int in a Value a bigint, u64 or i64?
yyp has quit [Quit: now it's safe to turn off your computer]
bitmapper has joined #zig
<ifreund> g-w1: yup
<g-w1> ok
<dimenus> is it expected that stage-2 doesn't require @as(usize, 42) to coerce to a usize?
<dimenus> where as stage-1 does
<g-w1> depends the context
<dimenus> inline asm in this case
<g-w1> in in the inline asm syntax specifically?
<g-w1> not sure, but generally stage2 is better with this type of stuff
<dimenus> i would assume that's intended
<dimenus> assuming comptime_int fits
waleee-cl has joined #zig
<ifreund> dimenus: yep that's right
<g-w1> no, i think stage2 inline asm syntax is just not complete
<ifreund> line 3020
<g-w1> for (inputs) |*name| {name.* = sema.code.nullTerminatedString(sema.code.extra[extra_i]); extra_i += 1;} this is how it handles inputs
<ifreund> of astgen.zig
<g-w1> then it passess that to codegen
<g-w1> or maybe not :)
<ifreund> the result location has type usize, so the @as(usize, foo) is implicit
<g-w1> is a BigInt as simple as a slice of usizes?
<ifreund> stage2 is just better than stage1 at this stuff already
<g-w1> like to make one is it just &.{1}?
<g-w1> or is it way more complicated :P
<ifreund> if you want to make 1, use the i64/u64
<g-w1> what about a u16 (doing errorToInt)?
<g-w1> i assume still u64
<ifreund> and yeah, i'm pretty sure it's more complicated
<g-w1> ok lol
<ifreund> see std/math/big/int.zig
<marijnfs> is it fine to remove from an arraylist in a loop?
<ifreund> marijnfs: the remove operations don't reallocate so I don't see why not... are you seeing a crash or something?
<g-w1> do you mean while looping over with `for (arr.items) |item|`?
<marijnfs> g-w1: indeed like that
<marijnfs> ifreund: i wonder if the for loop in that case jumps over the last item perhaps and crashes
<marijnfs> say you are at the last item, and delete it. The 'end' of the array is behind you which is a problem if you say use c++ like iterators
<ifreund> marijnfs: oh if you're doing that not it's not "safe"
<ifreund> a for loop will only terminate naturally after iterating the full length the slice was when iteration started
<ifreund> use a while loop here
frett27 has quit [Ping timeout: 240 seconds]
notzmv has quit [Ping timeout: 240 seconds]
sundbp has quit [Ping timeout: 240 seconds]
aerona has joined #zig
<g-w1> hmm, for @intToError, it needs to reverse-index a hashmap. it has the number, but needs the string which is in a string -> number hashmap. what is the best way to deal with this?
<ifreund> well you can have a parallel number-> string hashmap if you need lookups to be fast in both directions
<ifreund> or you can just iterate the first hashmap if you dont
riba has joined #zig
paulgrmn has quit [Ping timeout: 252 seconds]
<g-w1> do you think it warrants a parralell hash map?
<g-w1> the only case I can think of is @intToError at comptime
<ifreund> I'd say no unless profiling shows that its an issue
<g-w1> ok, ill put in a TODO
marijnfs has quit [Ping timeout: 240 seconds]
<ifreund> I don't think it warrants a TODO, I doubt anyone will use @intToError enough for it to become an issue
<g-w1> ok
sord937 has quit [Quit: sord937]
cole-h has quit [Ping timeout: 265 seconds]
wootehfoot has quit [Read error: Connection reset by peer]
<noam> Is it too late to try to sway #678 away from acceptance?
<noam> IMO, neither example in the OP should be allowed
skuzzymiglet has quit [Read error: Connection reset by peer]
<dimenus> seems like a regression
<dimenus> in stage-2
<dimenus> & zir-mem branch
notzmv has joined #zig
squeek502 has quit [Remote host closed the connection]
reductum has joined #zig
<g-w1> seems like it :P. but also you shouldn't return in a noreturn function :)
<g-w1> probably a bug in Sema
<dimenus> i know, i was expecting it to not compile :)
<dimenus> it was a typo that I thought i'd report
<g-w1> nice yeah
<g-w1> seems to be a bug in Sema.analyzeRet
<noam> Huh - that wouldn't even make it to sema in zyg :)
<noam> ... though upon testing it appears I forgot to even support operand-less returns lol
<ifreund> noam: why would anything before sema be smart enough to catch a return in an noreturn function?
<dimenus> ifreund: can you explain something to me re astgen.zig:438-472?
<dimenus> why is the lhs a usize rl?
<dimenus> ptr?
<noam> ifreund: type analysis is separate from semantic analysis in zyg
<noam> There's a dedicated pass to analyzing type information, validating that types are correct, and so on
<ifreund> noam: that sounds like a strange choice for a language with first class types at comptime
<noam> The type analysis can invoke the comptime engine where it needs to
<noam> Which, in turn, can invoke semantic analysis :P
<ifreund> dimenus: that would be because I was being stupid, will fix :D
<noam> ifreund: the decision was made purely from a readability standpoint
<noam> The compiler is designed to be as painless to maintain as possible, even if it comes at the expense of performance
<noam> (of itself, not of generated code)
<ifreund> noam: it seems to me you've just divided semantic analysis up into a few sub steps
<noam> Sorta?
<noam> Type analysis doesn't really understand *semantics*, just *types*
<noam> It knows a tiny bit - e.g. the result of a call type is the rettype of the called function, which should be checked against the type of the parent expression (e.g. in an assignment, a var)
<noam> ifreund: that's *technically* accurate, and it can be a decent way of thinking about it
<ifreund> dimenus: fixed, thanks for catching that :)
<noam> Maybe "type semantics analysis" is a good way of thinking about it
<ifreund> noam: which is my point and why I took issue with "Huh - that wouldn't even make it to sema in zyg :)"
<noam> whereas what i've been calling sema is more "executional semantic analysis"
* noam nods in agreement
<noam> I'll rename it later :P
<noam> maybe sema/{types,insns,usage} or something like that
<noam> Usage analysis depends on understanding of lazy analysis, which is a semantic feature of Zig, for instance
<dimenus> ifreund: np, i'm working my way up to useful contributions in stage-2 :)
<dimenus> that fix makes hello world work with slices
<dimenus> fg
<ifreund> oh I really should have added a test case
Akuli has quit [Quit: Leaving]
<ifreund> dimenus: what hello world with slices did you get working? I hit a TODO in sema
nycex has quit [Remote host closed the connection]
nycex has joined #zig
<dimenus> ifreund: i'm dumb, it was a ptr to an array. len just auto-derefed so i got confused
<dimenus> i incorrectly assumed that the string was a slice, not a pointer to an array
<dimenus> when i sliced the array, i got through to codegen though instead of failling in sema
<dimenus> fg
<dimenus> damnit, sorry
<ifreund> ah, no worries
<dimenus> fg
<dimenus> alright i'm done with irc for now
<dimenus> hah
<noam> You're never done with IRC. It's a matter of when IRC is done with *you*
<noam> :P
xackus_ has quit [Ping timeout: 240 seconds]
riba has quit [Ping timeout: 246 seconds]