ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
<Cadey> specifically, in zig/lib/std/special/start.zig `wasm_freestanding_start` is calling `callMain` but discarding the return code
<msiism> andrewrk: Ok, I just can't, well, I can't really put into words how exactly i don't understand that... I mean I (think I) understand what a data type is, like an integer value of 1 or the return type of a function. But then, a command, like `break` is “not data”, is it? That's why I can't really imagine what, e.g., `break` having a type would really mean.
<andrewrk> Cadey, ah yes. wasm32-freestanding does not provide a way to deal with the error code. your OS does, so wasm_freestanding_start is not the correct entry point. give me a sec I have a diff for you to try
<Cadey> :=1:
<Cadey> :+1:
<andrewrk> Cadey, can you try this diff? -> 2 things: (1) olin os package should export _start and call main (2) your target should be `wasm32-other`, not `wasm32-freestanding`
<andrewrk> msiism, "noreturn" is a type that means "not data"
<Cadey> andrewrk: from the os package, how do i call main()?
<Cadey> just `main()`?
<andrewrk> you can look at the file that diff patches as an example
<andrewrk> hm maybe the std lib should expose that callMain function
<msiism> andrewrk: Hm... ok. And what then is the rationale behind having a data type that has the meaning of ”not data”? (If that's already explained somewhere, a link will do.)
ur5us has quit [Ping timeout: 252 seconds]
<Cadey> andrewrk: std.os.raise unimplemented for this target
<Cadey> i'm gonna experiment with making callMain pub
<msiism> andrewrk: Ok, thanks. Seems like I simply ran into something here that's just way over my head. Not a big deal.
msiism has left #zig [#zig]
<andrewrk> Cadey, raise is getting pulled in from abort(), which is getting pulled in from the default panic impl
<Cadey> huh, i thought i had a panic impl already
<andrewrk> we should probably have a way to override the default panic in the os layer as well, check std/builtin.zig:425
<Cadey> ah yep, there's a way to override it
<Cadey> it's in `root.panic` though, would it be safe to move it to `root.os.panic`?
<andrewrk> yeah you can already override it per-application, but you probably can provide a better default in the os layer as well
<andrewrk> someone might want to override panic while using your OS layer package
<Cadey> true
<andrewrk> I suggest to allow OS layer override inside default_panic impl
<andrewrk> or you could provide abort() instead
<Cadey> still getting the `std.os.raise unimplemented for this target` error
ur5us has joined #zig
<andrewrk> here's another diff to apply
<Cadey> kk
<Cadey> `error: container 'std.os.system' has no member called 'abort'`
<Cadey> olin.zig:, allyourbase.zig:
<pixelherodev> std.os.system should be your OS layer IIRC
<pixelherodev> i.e. @import("root").os
<Cadey> yeah, that's what's confusing me too
<andrewrk> Cadey, fyi that panic function isn't pub
<pixelherodev> Cadey, you put it in a system struct
<andrewrk> pixelherodev, it is, look at
<pixelherodev> That's what I'm saying - wait - you mean it's *supposed* to be?
<pixelherodev> ... mine isn't...
<pixelherodev> Was the OS layer changed?
<andrewrk> I don't think so
<pixelherodev> I think that's wrong then
<andrewrk> pixelherodev, Indomitable has it in a system struct too
<pixelherodev> ... wait I do?
<andrewrk> yeah I sent you that PR
<pixelherodev> Ah, okay
<pixelherodev> Ah - `pub const system = if (@hasDecl(root, "os") and root.os != @This()) root.os.system`
<pixelherodev> That does root.os.system instead of root.os
<pixelherodev> Which now that I think about it makes sense
<pixelherodev> But doesn't solve the issue
<andrewrk> Cadey, I'm not sure why that error would be happening, can you double check stuff on your end? e.g. that the changes are getting picked up or whatever
<andrewrk> which line is giving the compile error?
<Cadey> /home/cadey/prefix/zig/lib/zig/std/os.zig:202:11: error: container 'std.os.system' has no member called 'abort'
<Cadey> and my copy of that file:
<pixelherodev> Huh
<pixelherodev> That's weird
<andrewrk> make sure your application file has `pub` on your `os`. in the example you provided it is correct, but the panic function is not
<Cadey> i do
<Cadey> assuming `pub const os` is the right order
<andrewrk> yeah that should be fine
<andrewrk> let me try to reproduce
<andrewrk> both my zig checkouts have dirty working trees, good thing I have a third checkout
<Cadey> i'm almost at the level of making a fresh zig environment in a docker container lol
traviss has quit [Remote host closed the connection]
<pixelherodev> andrewrk, if you have a third, then "both" isn't entirely accurate now is it? :)
<andrewrk> 🤔
<pixelherodev> Oh, and regarding the earlier " there's --emit llvm-ir"
<pixelherodev> I know, that's what I used to produce the test files
<pixelherodev> (along with --strip for good measure)
<pixelherodev> But if the goal is to remove LLVm
<pixelherodev> LLVM*
<pixelherodev> and my real goal is to support a backend to *Zig*, not *LLVM*...
<pixelherodev> Then I'm going to need to switch the input source :P
<pixelherodev> I was going to ask actually: is the goal to remove LLVM completely? Or just as a mandatory dependency for native compilation?
waleee-cl has quit [Quit: Connection closed for inactivity]
<andrewrk> pixelherodev, my eventual goal is to make it an optional dependency of self-hosted
<pixelherodev> And remove it entirely for stage2?
<pixelherodev> Real question:
<pixelherodev> Will stage2 be able to generate LLVM IR?
<andrewrk> the zig language specification will not mention LLVM
<pixelherodev> Right but practically
<pixelherodev> Will LLVM be an alternative to e.g. x86?
<andrewrk> the ability to output llvm ir will always be an "extension" or "implementation defined" feature
<pixelherodev> Is that true of e.g. ARM also?
<pixelherodev> And practically
<andrewrk> that's a good question, how architectures fit into it
<pixelherodev> I'd support having LLVM IR as a backend, even if the dependency on LLVM as a library is removed
<andrewrk> still not quite sure what you're trying to figure out. I feel like I probably can answer it but haven't understood the question yet
<pixelherodev> With `-target`
<andrewrk> oh I see
<pixelherodev> Sorry, starting over:
<pixelherodev> Basically, will there be an alternate to `-emit llvm-ir` in stage2?
<pixelherodev> e.g. `-target llvm-ir`?
<andrewrk> you're suggesting a use case of LLVM IR (or bitcode) as a target, not necessarily with the actual LLVM project as a dependency
<pixelherodev> Right
<pixelherodev> That's why I was interested in the idea of a Zig-specific IR, but I feel like LLVM as a target is a better option that trying to stablize a Zig-specific IR
<andrewrk> I'll have to think about how that might work. it wouldn't really be an architecture, because if it was then every sub-architecture would be all the other architectures
<pixelherodev> Oh, that reminds me
<pixelherodev> Is there a way to override the LLVM target to a custom definition for Zig?
<pixelherodev> stage1
<pixelherodev> Right now I'm using i386-freestanding since that's the closest match
<pixelherodev> But it's not fully accurate, and if I want to try targeting e.g. z80 I need more customization
<andrewrk> Cadey, ok I can reproduce
<Cadey> \o/ my environment isn't as insane as i thought it was