<g-w1>
andrewrk: I figured out why llvm-ar.id is in the cwd (#6943). it is because it is trying to save the digest of the cache hash of all the stuff in the archive. but it is putting it in the output directory, which is in this case the cwd(). the relevant line is llvm.zig:558. I do not know what the intended way to fix this is? is there a check in Compilation whether zig build called build-lib or a human
<g-w1>
on the cli called it? or should llvm-ar.id be put in zig-cache?
ur5us has quit [Ping timeout: 240 seconds]
<g-w1>
I think it could go in base.options.module.?.zig_cache_artifact_directory
<andrewrk>
nice g-w1 - I'll take a look at this tomorrow
hlolli has joined #zig
hlolli__ has quit [Ping timeout: 272 seconds]
hlolli has quit [Remote host closed the connection]
hlolli has joined #zig
a92 has quit [Quit: My presence will now cease]
hlolli_ has joined #zig
hlolli has quit [Ping timeout: 272 seconds]
jicksaw has quit [Quit: ZNC is kill]
jicksaw has joined #zig
earnestly has quit [Ping timeout: 240 seconds]
a_chou has joined #zig
layneson has joined #zig
a_chou has quit [Remote host closed the connection]
layneson has quit [Ping timeout: 256 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
mschwaig1 has quit [Ping timeout: 240 seconds]
mschwaig1 has joined #zig
factormystic has quit [Read error: Connection reset by peer]
sord937 has joined #zig
factormystic has joined #zig
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
decentpenguin has quit [Quit: ZNC crashed or something]
marnix has quit [Read error: Connection reset by peer]
decentpenguin has joined #zig
marnix has joined #zig
cole-h has joined #zig
gpanders has quit [Ping timeout: 246 seconds]
lucid_0x80 has joined #zig
ur5us has joined #zig
ur5us has quit [Client Quit]
plakband has joined #zig
lucid_0x80 is now known as suskun
marnix has quit [Ping timeout: 240 seconds]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
cole-h has quit [Ping timeout: 246 seconds]
earnestly has joined #zig
vesim has joined #zig
<vesim>
Hi, i have problems with versioned symbols in glibc, "lld: error: undefined symbol: memfd_create [...] did you mean: memfd_create@GLIBC_2.27" is there any workaround for that?
knebulae has quit [Read error: Connection reset by peer]
<ifreund>
vesim: what OS/zig version?
<vesim>
ifreund: 0.7.0+39336fd2e and arch linux
knebulae has joined #zig
<ifreund>
vesim: hmm, could you put the output of `zig build-exe --show-builtin` in a pastebin or something?
<ifreund>
I feel like it's detecting the wrong target or something
<pixelherodev>
I am once again considering spending time on a totally distinct Zig compiler...
<pixelherodev>
I *know* it's notworth the time...
<pixelherodev>
but I really want to :P
<ikskuh>
why?
<g-w1>
do you mean like a totally different implimentation?
<pixelherodev>
Yeah
<pixelherodev>
A pure C99 one
<ikskuh>
especially why before a specification
<ikskuh>
;)
<ikskuh>
it's not really worth the effort
<pixelherodev>
Because stage1 is awful, and while I like stage2, I dislike incremental compilation
<pixelherodev>
and I think I can make a simpler implementation...
<ikskuh>
then just make a non-incremental backend for stage2? :D
<ikskuh>
we need that anyways for release modes
<pixelherodev>
Eh, that kinda misses the point
<ikskuh>
why?
<pixelherodev>
"I dislike a feature" !-> "disable it!"
<pixelherodev>
I think stage2 is a tad overcomplex for my tastes
<pixelherodev>
Also: I think a pure C99 implementation from-scratch would be a better solution for bootstrapping than twisted the CBE to produce stage2-but-in-c
<ikskuh>
i think making a non-complex zig compiler is not possible :D
<pixelherodev>
CBE has always been intended as a fallback for where we don't have a working backend
<g-w1>
would you use assembly as output, or something else?
<pixelherodev>
Yeah
<pixelherodev>
I know I'm one of the ones who advocated for it, but... I find the idea of CBE-ing stage2 kinda repulsive after more thinking about it
<pixelherodev>
ikskuh: I heavily disagree
<pixelherodev>
Zig is inherently more complex than C, yes
<ikskuh>
by a lot
<pixelherodev>
Not as much as it appears at first glance
<pixelherodev>
There's one or two really big sources of complexity on which everything else is built
<pixelherodev>
comptime is the obvious one - but a *lot* of the "complexity" is really simple *once comptime is already in the picture*
<pixelherodev>
plus, *some* of the complexity is discarded
<pixelherodev>
e.g. preprocessing
<pixelherodev>
everything non-comptime is pretty simple
<g-w1>
do you think that your compiler could not have comptime, and just do manual generics and the sort?
<pixelherodev>
Nah
<pixelherodev>
I mean, yes, but I wouldn't
waleee-cl has joined #zig
<ifreund>
why not use qbe as the backend?
<ifreund>
from what I can see it would make implementing the C ABI stuff quite easy as well
marnix has quit [Ping timeout: 272 seconds]
marnix has joined #zig
lucid_0x80 is now known as suskun
actuallybatman has quit [Ping timeout: 256 seconds]
donniewest has joined #zig
marnix has quit [Ping timeout: 256 seconds]
marnix has joined #zig
LanceThePants has quit [Read error: Connection reset by peer]
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
sawzall has joined #zig
<pixelherodev>
ifreund: limited targets, mainly
<ifreund>
ah, yeah, x86 only so far
<pixelherodev>
and experimental arm!
<ifreund>
nice, the homepage made it sound like implementation hadn't started yet for arm
<ifreund>
jaredmm: use `zig translate-c` on the header then manually clean up the output and import the result as a normal zig file
xackus_ has joined #zig
<jaredmm>
That's what I've been doing. If I have multiple types shared between different libraries, will I need to manually generate them all to ensure that the type checking...checks out?
<jaredmm>
IE library B has `struct Some_Thing` that is defined in library A. Is there any way to alias those so that library A can still use cimport if library B has a problem?
<ifreund>
unfortuneatly not
<ifreund>
I recommend making a small c header that imports everything you need and then running translate C on that
hlolli_ has quit [Ping timeout: 272 seconds]
<jaredmm>
Aye. I was trying to add a new library after generating / cleaning up a few other ones and was looking for a way to not have to do that again. Not as reproducible as I'd like. Thanks for the confirmation.
<ifreund>
well you can always just paste the relevant extern defs from the new library into your already cleaned up code
<marler8997>
advice to programmers on how to make it easy to review their pull requests
<g-w1>
thanks. i needed that
commonlylen has joined #zig
<marler8997>
QUOTE "I often see authors treat their reviewers like personal quality assurance technicians"...lol
<jaredmm>
ifreund: That works for inconsistent type names, but it also generates duplicate definitions that I need to remove. Isn't difficult, but I am lazy.
<FireFox317>
andrewrk, are you available for a quick question about stage2?
<ifreund>
if you ask the question instead of asking to ask there's a chance someone else may be able to answer it as well
<FireFox317>
true ifreund. Its actually about code that you wrote, the wasm backend. Nypsie is working on stream currently to improve it
<ifreund>
oh cool
<FireFox317>
and for wasm you have to declare a section which stores which locals are used, however we are not sure where we should get this information from.
<FireFox317>
Like we can look at the Zir instructions and figure it out using that, or maybe this information is available in the module or something
<ifreund>
locals in wasm are like infinite registers
<ifreund>
look at the code doing register allocation
<andrewrk>
FireFox317, yep
<ifreund>
also be aware that the wasm codegen should almost certainly be integrated into the main codegen code path instead of being completely separate
<FireFox317>
andrewrk, so we are currently in codegen/wasm.zig and we have to figure out all the mutable local variables in a functions. Is this information avaialbe somehwere?
<ifreund>
I put it in a separate file just so I didn't have to understand the much farther along x86 code when figuring out the incremental compilation for wasm
<FireFox317>
ifreund, i see
<marler8997>
g-w1, just saw your PR, the realpath substituation may not work
<FireFox317>
so andrewrk, there is no information in Module or something, that tells us the mutable variables in a function? We have to look at the zir instructions for that?
<ifreund>
yes, you need to look at the zir. it may not correspond directly to the zig source code due to e.g. an optimization pass or similar
commonlylen has quit [K-Lined]
<FireFox317>
ifreund, okay yeah that sounds indeed logical, because maybe some variables are optimized away or something similar
<Nypsie[m]>
ifreund, thanks for the help btw. Much appreciated. Would it be correct to assume an Inst of tag alloc, would be a local in this case?
<ifreund>
afaik yes
<Nypsie[m]>
I see, thanks!
<ifreund>
I haven't done much with zir yet though
<andrewrk>
FireFox317, a local variable corresponds to an "alloc" instruction
<Nypsie[m]>
No problem, any help is appreciated. Just trying to understand more of stage2 as I go along. Would be cool to have some more wasm backend features implemented by the end of the month :)
<andrewrk>
FireFox317, the IR instructions in zir.zig are reasonably well documented
<g-w1>
does a comptime local variable have to have an alloc? trying to work on those and having trouble because codegen is trying to alloc a type
<ifreund>
I think the first step that needs to happen for wasm progress is getting it integrated into the main codegen.zig
<Nypsie[m]>
andrewrk, I think that also confirms my question to ifreund above, thanks
<FireFox317>
andrewrk, Thanks! That is really helpful
<Nypsie[m]>
ifreund, is that something you wanting to do by yourself, or something I could give a shot at?
<andrewrk>
g-w1, FireFox317, Nypsie[m]: the zir.zig instructions are pre-analysis; they are generated by astgen.zig. sema.zig takes these and outputs the instructions in ir.zig. then codegen.zig turns that into machine code
<andrewrk>
comptime stuff happens in sema.zig. by the time codegen.zig is doing anything, all comptime stuff has been resolved
<ifreund>
Nypsie[m]: go for it, My TODO list is 10 miles long
<g-w1>
the problem that I am running into is in rnWrap.ptr I have a function that returns a type, but astgen can't know that so it rlwraps a pointer. this causes a CoerceToPtrElem in the zir, so when trying to make alloc on a comptime variable emit mod.constVoid, it doesn't work because CoerceToPtrElem doesn't expect a constVoid
<g-w1>
s/rnWrap/rlWrap
<Nypsie[m]>
ifreund, great! Will keep you updated on the progress.
<Nypsie[m]>
andrewrk: That makes it a lot more clear. Thanks for that!
<g-w1>
it rlWraps it to a ptr in varDecl astgen.zig:514. Should I add a zir inst to check if it is a comptime or runtime value and do stuff based on that?
<andrewrk>
g-w1, it's hard to understand - can you show some example zig code / zir with your question?
<andrewrk>
thanks, it helps to see the case you're working on
<andrewrk>
g-w1, I think you might be taking on a very difficult task. In order to answer your question I essentially have to go implement it myself
<g-w1>
ok. I guess comptime locals are harder than I thought. Ill work on another part of the compiler, thanks. its funny how solving one TODO about checking mutability in alloc spirals into implimenting comptime :)
<andrewrk>
yeah haha. everything is related
sawzall has quit [Read error: Connection reset by peer]
LanceThePants has joined #zig
LanceThePants has quit [Read error: Connection reset by peer]
LanceThePants has joined #zig
riba has joined #zig
ave_ has quit [Quit: Ping timeout (120 seconds)]
lunamn has quit [Quit: Ping timeout (120 seconds)]
ave_ has joined #zig
jjsullivan1 has quit [Remote host closed the connection]
jjsullivan1 has joined #zig
FireFox317 has quit [Ping timeout: 240 seconds]
marnix has quit [Ping timeout: 272 seconds]
cole-h has quit [Quit: Goodbye]
sord937 has quit [Quit: sord937]
xackus_ has quit [Read error: Connection reset by peer]
xackus_ has joined #zig
cole-h has joined #zig
<pjz>
why does zig complain about extra ;s ?
<pjz>
eg. if I put a ; after a for or while
<pjz>
I guess empty statement isn't a valid statement?
<andrewrk>
the more "negative space" there is, the less likely that a typo or other human error ends up manifesting in runtime behavior
<andrewrk>
that is why zig syntax is generally strict
<andrewrk>
Congrats to Jakub Konka who is now a part time paid contractor for ZSF! š
<BaroqueLarouche>
woot!
<pjz>
maybe better error location then? adding an extra ; after a block doesn't throw an error until the _next_ block or something
<pjz>
wow, gz!
<pjz>
<-- trying the advent of code
<andrewrk>
yep there is always room for improving error messages. I hope you can understand why I would tend to prioritize spending effort other things though. for example finishing the language
<pjz>
sure sure
<pjz>
just one of those things that noobs will bump into that more experienced people won't
<pjz>
though I'm not sure about the rationale of 'negative space'
wootehfoot has quit [Read error: Connection reset by peer]
Akuli has quit [Quit: Leaving]
<pjz>
empty _blocks_ are legal
<pixelherodev>
Congrats!
<andrewrk>
pjz, we need a way to represent the void value
donniewest has quit [Quit: WeeChat 3.0]
<pixelherodev>
andrewrk: how much change do you expect between 0.7 and 1.0 to the language itself?
joaoh82 has joined #zig
joaoh82 has quit [Ping timeout: 265 seconds]
<ifreund>
well, all the accepted proposals for one
<pixelherodev>
Well yeah :P
<pixelherodev>
I need to plan out my current projects, but I think I have time for a Zig compiler...
<pixelherodev>
Especially if it's intended for maximum simplicity
<ifreund>
an alternative implementation before 1.0 would be quite unusual :D
<pixelherodev>
andrewrk: if I get a C-based implementation ready, would that be an acceptable alternative to the CBE bootstrapping plan?
greisean has joined #zig
<ifreund>
that seems like a lot of duplicated effor
<pixelherodev>
Not really
<pixelherodev>
Just the opposite; it's intended to *replace* other effort
<pixelherodev>
It'd probably replace the CBE on my priority queue, but I'd still be able to help others who wanted to help out (as I did with tetrux's emit-h PR)
<ifreund>
as I understand it the plan is to wait until shortly before 1.0
<ifreund>
to do the one time translation
<pixelherodev>
Yeah, but it means a) distorting CBE into something it's not meant to do and b) cleaning up the generated code afterwards, which is explicitly mindless tedium
<pixelherodev>
and the result *still won't be* great
<pixelherodev>
What I'm proposing is a vastly simpler solution
riba has quit [Ping timeout: 240 seconds]
<ifreund>
you don't have to implement codegen for all targets twice
<pixelherodev>
I wouldn't be supporting every possible target, of course
<andrewrk>
why don't you start by replacing stage1's buggy comptime implementation with a super clean one that uses less memory?
<pixelherodev>
Because I'm not convinced stage1 is salvageable?
<pixelherodev>
:P
<pixelherodev>
More helpfully, isn't it already tightly integrated?
<pixelherodev>
Also, one of my goals here is to get a compiler I actively *like*; stage2 is much closer than stage1 for me, but a simple and clean design would be much much closer
<pixelherodev>
Cleaning up stage1 would be nice... but it'd still depend on LLVM, it'd still be a memory hog without *significantly* more effort than a clean slate
<ifreund>
I mean, if you want to do it, I say do it
<pixelherodev>
Thing is, it'd detract from my CBE efforts
<pixelherodev>
and while *I'd* prefer a fresh C implementation over the CBE bootstrapping plans, I'm not the only person affected by this decision
<ifreund>
personally I think that the CBE one time translation path is the most reasonable way forward
<pixelherodev>
Why's that?
<pixelherodev>
To be clear, CBE is explicitly designed to generate binaries masquerading as C, not C source code
<pixelherodev>
The entire point is to support platforms which have a C compiler but no Zig backend; there have been a number of design decisions already that harm generated code readability
<pixelherodev>
CBE one time translation means, effectively, rewriting the CBE to make more readable source, doing a one time generation, *deleting that CBE rewrite entirely*, and then cleaning up the generated code - which will not be trivial by any means
<ifreund>
It means that the focus is 100% on the self hosted compiler from the moment it can replace stage1 until shortly before 1.0 when the translation occurs
<pixelherodev>
Yes, which is only a plus if you consider the self hosted compiler to be a superior alternative to a from-scratch design anyways
<ifreund>
which I do, I want crazy fast compilation for big projects
<BaroqueLarouche>
the sooner I get packed struct that works, the sooner I'll be happy :D
<pixelherodev>
If I haven't made it clear, I don't; entirely subjectively, I have a major dislike for the incremental pipelining, direct machine codegen, etc
<ifreund>
and a built in language server
<pixelherodev>
That too
<pixelherodev>
That's another thing I consider abhorrent
<pixelherodev>
For, again, entirely subjective reasons
<pixelherodev>
I'm of the opinion that my compiler should be a compiler *and nothing else*
<ifreund>
you're right that your version of the compiler would be a hell of a lot easier to maintain for bootstrapping
<andrewrk>
zig eats a lot of complexity to provide simplicity for the programmer
<pixelherodev>
andrewrk: yes, but there's additional complexity which I'd argue doesn't serve that purpose
<andrewrk>
sometimes this complexity can leak, especially pre-1.0
<pixelherodev>
As mentioned in the last few minutes: incremental compilation, in-compiler LSP support
<ifreund>
incremental compilation is an awesome feature for users IMO
<andrewrk>
zig compiling things fast prevents people from reaching for hacky half-measure solutions to the problem
<pixelherodev>
I also think it's a tad hypocritical of us to explicitly say that the CBE should only ever be used to produce binaries and not for source generation and then to turn around and do exactly that :(
<pixelherodev>
If source generation is a reasonable idea, then the CBE should support that more generally
<ifreund>
It doesn't really belong in a compiler written in C intended for bootstrapping though
<companion_cube>
(what's "CBE"?)
<pixelherodev>
C backend
<companion_cube>
oh, I see.
<pixelherodev>
Zig->C translation
<pixelherodev>
I'd also argue that compilation can be plenty fast without it
<companion_cube>
useful for some targets, like embedded, I guess
<pixelherodev>
tcc can manage 30MiB/s of compilation+assembly+linking on a Pentium.
<pixelherodev>
Even half of that should be more than enough
<pixelherodev>
and I don't think Zig is so much more complex than C that it'd need twice the compilation time
<ifreund>
depends on how much people abuse comptime
<companion_cube>
it might not be that easy to compile release-safe to C?
<pixelherodev>
True
<pixelherodev>
comptime abuse would be a problem
<pixelherodev>
But honestly, if someone abuses the language, it's not our job as compiler devs to help them
<ifreund>
I for one think that caching of comptime evaluated stuff through incremental compilation will be *very* nice to have
joaoh82 has joined #zig
<ifreund>
If comptime abuse is what it takes to replace C++ I'm all for it
<pixelherodev>
I'm not
<pixelherodev>
I think it says more about the language if it's capable of replacing C++ like that :P
<andrewrk>
" if someone abuses the language, it's not our job as compiler devs to help them" => wrong. it is always our job to help users. if they are abusing the language it is because they have some need that is not being met. our job is to have a solution to that use case that does not involve abusing the language, whether it is an unrelated improvement, or providing better documentation to help users find other projects to use instead
<pixelherodev>
Our job isn't to help them *with the language abuse*
<pixelherodev>
To help them not *need* it, sure
<BaroqueLarouche>
well said andrewrk
<pixelherodev>
but if someone abuses C++ templates, and then complains that compilation takes forever, the solution is to stop abusing templates and find a better solution
<pixelherodev>
if someone abuses comptime, the solution isn't "make comptime faster" (throw more software at the problem!), it's to find a solution that doesn't require such abuse
<pixelherodev>
Or, more generally: we should prioritize correct use of the language over misuse
<companion_cube>
and that's why there will be several compilers :)
<fengb>
Comptime rainbow tables š¤
<pixelherodev>
If a compiler change makes it simpler, and improves performance generally by ~3%, but decreases it for comptime abuse by 50%, I'd still support it
<BaroqueLarouche>
am I the only one that doesn't want several compilers ? Just focus on 1 great compiler
<pixelherodev>
BaroqueLarouche: might as well complain about GNOME/KDE/XFCE/LXDE/Sway/i3/dwm/openbox/etc
<fengb>
Iād settle for 1 mediocre one if it fixed packed structs š
<BaroqueLarouche>
(except for the bootstrap one of course)
<BaroqueLarouche>
pixelherodev: I already do
<andrewrk>
fengb with the hottest of takes
<pixelherodev>
For anything in that list, there are a *lot* of people who consider it total garbage
<dominikh>
IMO you want at least two compilers. it helps a lot with creating a more precise spec and solving ambiguities
<pixelherodev>
I consider both GNOME and KDE garbage, and wouldn't touch them if you paid me
<pixelherodev>
Plenty of people would say the same thing about the systems I use
<pixelherodev>
That's not a *problem*
<greisean>
:O
<pixelherodev>
People have different philosophies and desires
<pixelherodev>
There's no such thing as a one-size-fits-all solution
<pixelherodev>
"The linux desktop is too fragmented!!" is a ridiculous argument, because it implies that there is "a linux desktop". KDE and GNOME are both huge bloated ecosystems IMO, and I consider them to be totally awful - but that doesn't mean that I'm going to pretend that they're identical
<BaroqueLarouche>
I'm not using Linux anymore because it's a fuckin' mess
<pixelherodev>
All that wouold happen if they tried working on "one grand desktop!!" would be a system users of *both* DEs would loathe
<companion_cube>
BaroqueLarouche: if you want a language to have a true spec and standard, you have no choice but having several compilers
<companion_cube>
you may not want that, of course
<pixelherodev>
Multiple compilers doesn't mean work is being spread too thin; it means different people are all getting what they want out of the language
<companion_cube>
amusingly, I think SML and Scheme are probably among the most precisely standardized languages
<pixelherodev>
I like cproc as my main C compiler; other people prefer GCC; others will stick with Clang, or TCC; I use the plan9 compilers daily nowadays;
<pixelherodev>
If any one of these didn't exist, we would all be worse off
<pixelherodev>
and I say that as someone who hates half the items in the list!
<pixelherodev>
I loathe GCC and Clang; I dislike Rust and C++, Windows and OS X. I'm still glad everything on that list exists, even though I don't like them.
gazler_ has quit [Remote host closed the connection]
joaoh82 has quit [Ping timeout: 240 seconds]
gazler_ has joined #zig
<pixelherodev>
Heck, Zig as it is today probably wouldn't exist without half the items mentioned on that list. You might as well complain that effort on Zig is wasted and that Andrew and all of the other devs should have just improved the C compilers instead; it's just not a reasonable idea
<g-w1>
imho, pixelherodev: i can see that you really want to write another compiler and I say: go for it! even if you decide it's not worth it, it will teach the community a lot
<andrewrk>
14 issues left for 0.7.1
<pixelherodev>
nice :)
<ifreund>
My take is that the global maximum bootstrapping compiler would look very similar to what pixelherodev is describing. It would almost certainly be easier to maintain than the source generated from the CBE and would be far easier to work on than stage1
<ifreund>
if people like using it for more than just bootstrapping, that's cool too
<ifreund>
hmm, I wonder if I can fix any of the 0.7.1 issues. waiting on that release to merge a large branch into river