ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
francis36012 has joined #zig
unique_id has joined #zig
<unique_id>
Let's say that I'm creating a library. I point build.zig to src/index.zig. index.zig has "pub const X = @import("X.zig")". Inside X.zig there's an exported function (pub export fn foo() void {}). However, because the symbol X inside index.zig is never used, then X.zig is never visited, and foo never makes it into the library.
<unique_id>
Isn't that a bit strange?
<andrewrk>
yes it is
<andrewrk>
the current workaround is: comptime { _ = @import("X.zig"); }
<unique_id>
ok
<andrewrk>
but you are not alone in thinking that it is awkward
<andrewrk>
a problem we have to solve to fix it, is to decide whether or not it's a feature that you can conditionally @import something at comptime
<andrewrk>
right now it's a feature
<andrewrk>
so zig can't follow that @import("X.zig") for the same reason that it can't follow both of these imports in the same build: const x = if (builtin.os == builtin.Os.linux) @import("linux.zig") else @import("other.zig");
<unique_id>
I see
<MajorLag>
andrewrk, can I get a clue about this compiler assert: "unreachable: /deps/zig/src/ir.cpp:ir_analyze_container_field_ptr:14618"
<unique_id>
Imports have a dual purpose in that they not only let you make use of the file you imported, but they also specify that it's part of the project. If the files belonging to a project were instead declared differently, perhaps declaratively in some way, then knowledge of which files are included in a project would be known at an earlier time in the compilation process, perhaps aiding any future attempts are distributed compilation (if
<unique_id>
that ever becomes a thing). Also, declarative knowledge of files would reduce funny business (really odd import paths hidden away in some file).
<daurnimator>
andrewrk: I have a different idea
<daurnimator>
andrewrk: what if 'extern' only applies on a per-import basis
<daurnimator>
i.e. it is "extern" to the file
<daurnimator>
if another module wants include its exports, then it has to: `extern @import("foo.zig").*` or similar
qazo has joined #zig
qazo has quit [Ping timeout: 245 seconds]
<MajorLag>
andrewrk: looks like it has something to do with async<> and the new Allocator. does async<allocator> call (alloc|realloc|free)Fn by chance?
reductum has quit [Quit: WeeChat 2.3]
<MajorLag>
hmmm... nope. adding functions with those names back to the interface didn't help
<MajorLag>
Ah, ok. It's a combination of two things: async<allocator> expects allocator to be a pointer, and the new interface is passed as a copyable struct of pointers, as well as it explicitly looks for the (alloc|realloc|free)Fn functions. I can work around this for now. As I recall, passing an allocator to async is being phased out anyway.
<MajorLag>
hmmm... maybe I can't work around it. It seems upset about the fns technically being bound fns.
<MajorLag>
well, I'm giving up on that for tonight.
oconnor0 has quit [Ping timeout: 256 seconds]
Ichorio has quit [Ping timeout: 272 seconds]
<daurnimator>
MajorLag: yeah after copy ellision is done then async shouldn't need an allocator
<daurnimator>
MajorLag: though the exact changes needed for that *may* only come after the whole coroutine rewrite.
<MajorLag>
well, as long as we can accept that any test that analyzes async<allocator> will fail until then...
<MajorLag>
otherwise I'm blocked on this
<MajorLag>
well, assuming I can't figure out some workaround
Ichorio has joined #zig
francis36012 has quit [Ping timeout: 250 seconds]
redj has quit [Ping timeout: 272 seconds]
Ichorio has quit [Read error: Connection reset by peer]
qazo has joined #zig
qazo has quit [Ping timeout: 245 seconds]
qazo has joined #zig
qazo has quit [Ping timeout: 250 seconds]
qazo has joined #zig
<andrewrk>
I recommend avoiding coroutines until the rewrite
emekoi has joined #zig
<emekoi>
how hard would it be to get `@returnAddress` to work like `__builtin_return_address`?
redj has joined #zig
IntoxicatedHippo has joined #zig
emekoi has quit [Ping timeout: 272 seconds]
IntoxicatedHippo has quit [Quit: Leaving]
xentec has quit [Ping timeout: 272 seconds]
xentec has joined #zig
unique_id has quit [Quit: Konversation terminated!]
francis36012 has joined #zig
francis36012 has quit [Ping timeout: 272 seconds]
<knebulae>
andrewrk: it appears that an assumption is made that if you are importing C code, that that C code *must* depend on libc. This is not always a true assumption. Thoughts?
diltsman has quit [Ping timeout: 256 seconds]
fsateler has quit [Quit: ZNC 1.7.1+deb2 - https://znc.in]
fsateler has joined #zig
<MajorLag>
is there no way to specify an exact match for --test-filter?
steveno__ has joined #zig
kristate has joined #zig
<MajorLag>
> error: expected type 'AllocatorInterface(AbstractAllocator)', found 'AllocatorInterface(AbstractAllocator)'
<MajorLag>
It would seem fate is against reforming interfaces in std
<MajorLag>
the best part is that it points to the exact same place for both definitions
Ichorio has joined #zig
<MajorLag>
wait, no, one of them is pointing to a different copy of std for some reason. Mystery solved.
<MajorLag>
actually, the same copy of standard but via a different import path
<MajorLag>
is that a known issue?
<kristate>
MajorLag: do you have a gist somewhere that we can look at?
steveno_ has joined #zig
steveno__ has quit [Ping timeout: 250 seconds]
<MajorLag>
of the import thing? No, but I'm sure I could create one in a few minutes.
<MajorLag>
side note: it looks like there are several tests in standard that are not run by the default testing regime, because they fail for reasons having nothing to do with my changes. I'll make a note of each and an issue for all of them.
Zaab1t has joined #zig
Zaab1t has quit [Quit: bye bye friends]
oconnor0 has joined #zig
steveno_ has quit [Ping timeout: 250 seconds]
Ichorio has quit [Ping timeout: 245 seconds]
Ichorio has joined #zig
steveno_ has joined #zig
<andrewrk>
knebulae, that's a really tricky problem
<andrewrk>
emekoi, you want the level parameter? it's exposed by LLVM. want to open an issue so we can discuss it?
<knebulae>
andrewrk: I may have solved it (for now).
<andrewrk>
knebulae, I do want to support the use case of linking against C code with no libc
<knebulae>
right
<andrewrk>
I think as a workaround right now you can use `zig build-obj` and `zig build-exe` separately
steveno__ has joined #zig
steveno_ has quit [Remote host closed the connection]
Shankar has joined #zig
<MajorLag>
so one of the errors I ran into actually is tested by CI. it only seems to error on my machine. `std/special/compiler_rt/index.zig` tests "test_umoddi3" and "test_udivsi3" can't inline `extendXfYf2` or `truncXfYf2`
<andrewrk>
MajorLag, hmm this is triggering a vague memory of me running into this issue
<andrewrk>
I think it's ok to remove the `inline` keyword
<andrewrk>
I think that the endgame for `inline` in zig is that we'll do it in the frontend
<j`ey>
why?
<andrewrk>
right now the error for failing to inline is the only compile error that we have to look at the LLVM IR post-optimization to see if it worked
<andrewrk>
it's brittle. plus doing the inlining in the frontend gives zig more information, if we do advanced control flow analysis
<j`ey>
so inline is actually 'always_inline'?
<andrewrk>
yes
<andrewrk>
zig has no "inline hint"
Zaab1t has joined #zig
<oconnor0>
andrewk, have you seen LLVM not inline functions marked always_inline?
meheleventyone has joined #zig
kristate has quit [Remote host closed the connection]
<knebulae>
andrewrk: Can you shed some light on line 30 in std/os/index.zig? Why is a compiler error thrown if the target is not posix?
<andrewrk>
knebulae, zig has lazy analysis. any code that is not run on a posix system should not reference that `posix` identifier, and so won't hit that compile error
<andrewrk>
but if you, for example, do `posix.write()` on windows, you'll get the compile error
<andrewrk>
oconnor0, it happens for example if the function references itself, directly or indirectly, or if you take a function pointer to it. MajorLag is also observing it for an unknown reason
<MajorLag>
The VM i'm working with is highly constrained. For instance I have to run tests individually to avoid running out of memory. Could be related.
<knebulae>
I was hitting it, that's why I wondered. :/
<andrewrk>
knebulae, can you give a link to a paste of the error you're seeing?
<andrewrk>
oh, sorry never mind, I thought you were talking about the inline thing
<andrewrk>
knebulae, I think we have an open issue for that to give a better compile error note trace of why the symbol is depended on
<andrewrk>
although I thought it was already solved
<knebulae>
no biggie. I'll figure it out.
<andrewrk>
knebulae, as a workaround, you can try deleting the line that declares posix, and see if that compile error is better
<knebulae>
My biggest concern right now is that there are two open-source implementations of the UEFI runtime libraries. GNU (GPL) and TianoCore (Intel/Apple/et. al.) (BSD). If I add some runtime support to std, I'll need to do it twice via an overlay layer.
<andrewrk>
when your uefi application is executed on actual hardware, is the runtime library provided by the hardware? or is it statically compiled into your executable?
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<knebulae>
andrewrk: the runtime is linked into the executable.
<knebulae>
but it is not in any way a traditional c runtime
<andrewrk>
I just looked at the UEFI spec and it is a 2,575 page PDF
<knebulae>
yeah, it's obscene.
<andrewrk>
that must be the C code you wanted to link without linking libc?
<knebulae>
Yessir
<andrewrk>
I think that's a good solution for a proof of concept. uefi runtime library implemented in zig would be neat, if not in std then in a third party package
<andrewrk>
I don't know how complicated a uefi runtime library is
<knebulae>
it would be minimal to provide the few functions needed by std. but it is not libc and it is definitely not posix.