<g-w1>
is an error union ever not a valid var type?
Techcable has quit [Remote host closed the connection]
<andrewrk>
just arm left todo now in the llvm12 branch
<andrewrk>
after this, the "Upgrading to new LLVM" process will get a much simpler, at least as far as cpu features goes :)
leon-p has quit [Quit: leaving]
raggi has joined #zig
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
kbd has joined #zig
<g-w1>
andrewrk: if implimenting runtime error comparisons for the cbe, should I make a new tzir inst for error comparison? or is there already something that I can use?
brzg has joined #zig
<g-w1>
should I just use cmp_eq?
<g-w1>
for the cbe, cmp_eq will work I think, but idk about the other backends since they use intInfo so I would have to add some error specific code in there
Techcable has joined #zig
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
kbd has joined #zig
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
earnestly has quit [Ping timeout: 256 seconds]
osa1 has quit [Ping timeout: 246 seconds]
<andrewrk>
g-w1, which type are we talking about here? error set or error union?
<g-w1>
error.Val
<g-w1>
see zir_sema.zig:2221
<mikdusan>
andrewrk: does zig change debug info generation based on build-type? ie: an arg is a slice VS an arg is a ptr + len ?
<mikdusan>
if my question doesn't make sense just say so :)
<andrewrk>
g-w1, that's a value with type of error set. in codegen, every TZIR instruction will have a corresponding machine code value. this machine code value will be a simple integer and can be compared directly
<andrewrk>
TZIR tag of cmp_eq is ok to pass to codegen for error set values
<g-w1>
ok, so in genCmp in codegen.zig I will have to check if it is an error set and then do different stuff right? since it has no intinfo
<andrewrk>
mikdusan, the answer to the first question is "no", but I don't understand how the second clause relates
<mikdusan>
i added a comment to #6408 and am perplexed why in RELEASE the two slice args end up as (ptr,len) and in DEBUG the two slice args end up as (<unavailable>),(ptr,len)
<mikdusan>
ie: RELEASE loses the first arg "path" ? wtf.
<mikdusan>
if nothing comes to mind I'll continue digging
<andrewrk>
mikdusan, flattening a struct into args is a nice optimization
<andrewrk>
optimizations have to try to produce debug info that describes the original source
kbd has joined #zig
<andrewrk>
it's very common for a release build to have <unavailable> or <optimized out> things
<mikdusan>
we have debug info for same function (path: []const u8, expect: []const u8) vs (expect: (ptr, len)) <-- in the 2nd arglist, there is no "path"
<andrewrk>
bad debug info would not cause a test failure; you can strip debug info and it still runs the same
<andrewrk>
mikdusan, I'm guessing that test failure is unrelated to #6408
<mikdusan>
yeah I have a few other angles I think may reduce #6408 proper
brzg has quit [Quit: leaving]
squeek502 has quit [Remote host closed the connection]
<andrewrk>
mikdusan, done! invoking that update_cpu_features.zig tool now produces an empty git diff in the llvm12 branch
<mikdusan>
very nice!
<mikdusan>
have you ever tried building llvm with LLVM_ENABLE_EXPENSIVE_CHECKS=ON ?
<andrewrk>
not that I recall
<mikdusan>
ok I'll try it out while building a few variants of llvm
<andrewrk>
I kicked off the first test suite run of llvm12, now that the cpu features are repaired. let's see how it fares
<g-w1>
hmm, I am trying to work off of one of vexu's prs. it is not rebased with master, but I need it to be to add my features (error testing stuff in his cbe error pr) what is the best way to do this with the least breakage/headache?
<g-w1>
make a branch off his pr then rebase with master? merge with master? ask him to do it?
<mikdusan>
rebase his pr. rebase your branch. merge his pr to your branch.
<g-w1>
i tried merging with master but it showed all the commits in my pr so I thought that was not the right way to do it
<g-w1>
the easiest solution is probably just to ask him to rebase
Techcable has quit [Remote host closed the connection]
<mikdusan>
andrewrk: looks like all the syms in `c.o` which libc.so.6 links against are HIDDEN . vs 50% hidden 50% not when built from master
<andrewrk>
mikdusan, it fixed it to take away hidden, but looking at the symbols I wonder if some of them should be hidden
<andrewrk>
yeah in master branch the ones with version numbers are LOCAL HIDDEN and the bare names are GLOBAL DEFAULT
<andrewrk>
damn I bet TheLemonMan would know how to fix this
<andrewrk>
we need a batman search light but instead of the bat logo it is the shape of a lemon
ky0ko has quit [Remote host closed the connection]
<mikdusan>
hmm i might have a hint
<mikdusan>
adding a -v to `zig clang` for c.s -> c.o here is what shows for llvm-11:
<mikdusan>
(putting in a gist)
<mikdusan>
well it's one diff in `-cc1as` command line; llvm-12 **ADDS* this:
<mikdusan>
--mrelax-relocations
<andrewrk>
that sounds unrelated
<mikdusan>
ok
<andrewrk>
dalias from #musl said it sounds like a regression in clang
<mikdusan>
used clang from my toolchain and... clang11 c.s -> c.o is good. clang12 all same args, and generates 100% hidden symbols .
<mikdusan>
so sounds like a regre
squeek502 has joined #zig
squeek502 has quit [Remote host closed the connection]
squeek502 has joined #zig
osa1 has joined #zig
craigo has quit [Ping timeout: 265 seconds]
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
<andrewrk>
mikdusan, I just had a chat with the person who made the relevant change to clang. apparently it was a bugfix. and now there is no way to get the previous behavior
<mikdusan>
what's the birds-eye here... I didn't see in logs how `c.s` actually got created. do you run a bunch of internal `clang -S` on glibc sources?
<andrewrk>
mikdusan, how is that an improvement on the .s file we generate?
<mikdusan>
the .so with above `one()` has:
<mikdusan>
DYNAMIC SYMBOL TABLE:
<mikdusan>
00000000000012d0 g DF .text 0000000000000006 GLIBC_2.2.5 oney
<mikdusan>
and same so via readelf:
<mikdusan>
Symbol table '.dynsym' contains 2 entries:
<mikdusan>
Num: Value Size Type Bind Vis Ndx Name
<mikdusan>
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
<mikdusan>
1: 00000000000012d0 6 FUNC GLOBAL DEFAULT 8 one@@GLIBC_2.2.5
<andrewrk>
the problem is when there are multiple versions for the same symbol name
Thale has joined #zig
<Thale>
Hello
<Thale>
I'm just trying to comile my program on linux, coming from windows. So I downloaded the latest linux binaries. But when I compile it, I get the following error:
<andrewrk>
hello
<Thale>
Semantic Analysis... ./src/data_structures.zig:89:13: error: expected function or variable declaration after pub
<Thale>
Is this because something has changed in the language or am I doing sth wrong?
<andrewrk>
Thale, run `zig fmt` on your code. it will auto-update the `inline` to the new syntax
<Thale>
Ahh cool, thanks!
<mikdusan>
andrewrk: you're right same deal. I tried using __attribute__((visibility ("hidden")) from .c source and still marked its counterpart as hidden
podge has quit [Ping timeout: 246 seconds]
podge has joined #zig
<mikdusan>
hmm grep'ing glibc sources this pattern comes up. I have no idea what 'set' does or if it is ia640-only
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
<ifreund>
> @: start a builtin expression and/or access a builtin object, escape with $@
<ifreund>
marler8997: is this a typo? it seems to me that escaping with @@ would be more intuitive...
<ifreund>
oh but you seem to be using @@ for delimited strings now. hmm
<ifreund>
I'd probably use something else, say @%"foo" for delimited strings and use @@ to escape @. Using @$ to escape $ instead of $$ is the right call I think
<marler8997>
Yeah I wasn't sure what would be a good character for delimited string literals
<ifreund>
kakoune uses % in a somewhat similar way which is what made me think of it
<marler8997>
@@"..." looks farily clean, @$"..." looks a bit uglier to me, and @@"..." is easy to type
<marler8997>
If I were to use the same, I'd be adding 3 special characters, ', " and %
<ifreund>
Yeah I'm not sure if it's a perfect fit for stitch, but certainly food for thought :)
<ifreund>
I've found it quite plesant to use in practice
<marler8997>
found kakoune pleasent to use?
<ifreund>
kakoune and this syntax in particuar
<marler8997>
yeah I like it actually
<marler8997>
oh, and if the closing delimiter is double it's considered apart of the string
<marler8997>
interesting idea, but it kinda defeats the purpose of the delimited string, that its a WYSIWYG string
<ifreund>
well, it's either that or completely disallow the delimiter in the string
<marler8997>
right
<marler8997>
I'm thinking if have to esacpe your delimiter, just use a different delimiter
<ifreund>
indeed, though with that approach there are strings you can't encode
<ifreund>
e.g. a string containing every character
<marler8997>
you could still do %"hello "@"Joe@"
<marler8997>
by that I mean, end the delimited string and tak on more
<ifreund>
another approach I've seen is something like @``string here`still in the string``
<ifreund>
where you can use an arbitrarily high number of ` at the start, and the string continues untill that same number is found consecutively
<ifreund>
I think that can't handle empty strings though
<marler8997>
If we didn't add any special characters, what about @' to start a delimited raw string?
<marler8997>
@''hello'
<marler8997>
single-quote could be the default conventional delimiter
<marler8997>
I think I'll switch to that for now, and make a note about kakoune's syntax to consider
<ifreund>
hmm, aesthetically @''hello' feels unbalanced to me
<ifreund>
I think I'd go with @"hello" as the standard string with no way to escape "s between the quotes, and also have the @```foo``` syntax to allow arbitrary string contents
<ifreund>
then you don't need arbitrary delimiters as you can always add more `s
<ifreund>
and you have @"" for the empty string edge case
<marler8997>
not bad
<marler8997>
I'm very tempted to just allow "..."
<marler8997>
one big reason is that " almost always a special character, and people will expect it to be
<ifreund>
true, you could also go with what I just proposed but drop the @s
<marler8997>
so it would be "this is a string" or @`this is a "string" that can use double quotes`
<marler8997>
I could do the same with just double quotes right?
<marler8997>
"""this is a string"""
<ifreund>
yeah, but then you can't handle the empty string
<marler8997>
@emptystring :)
<ifreund>
fair enough :P
<marler8997>
or (@echo)
<ifreund>
that works, but it would be kinda suprising to find out that was the only way to write an empty string as a newcommer I think
<marler8997>
yeah, we might be able to do better
<marler8997>
So maybe "..." and @""""....""""
<marler8997>
or the other way? @"..." """"....""""
<ifreund>
in that case people would likely only use @"" for the empty string
<ifreund>
it would be in practice """...""" and @""
<ifreund>
which might be fine tbh
<marler8997>
yeah that seems odd
<marler8997>
If we suppsed "...", then using something like @%X...X seems more tractable than without "..."
<marler8997>
because @%X...X would be alot more rare
<ifreund>
if we used a delimiter that is a matching pair, the """...""" syntax can represent the empty string
<ifreund>
<<....>>
<ifreund>
<>
<ifreund>
could also go the other way and do >...< >>>...<<< ><
<marler8997>
interesting
<marler8997>
so may ways!!
<ifreund>
i kinda like >hello< tbh
<marler8997>
yeah it has a certain look to it that's appealing
<marler8997>
I think supporting double quote "..." is probably the right way to go, so I think we can simplify and assume that one
<marler8997>
with no way to escape the double-quote
<marler8997>
>hello ! this is a "string" with all sorts of character<
<ifreund>
if we were to break with most programming languages and go with >foo< for strings, we wouldn't need "..."
<marler8997>
>hello<
<marler8997>
>>my <xml> tag<<
<marler8997>
>>my stitch string >hello<<<
<marler8997>
oh that wouldn't work
<ifreund>
ah yeah, you can't end the string with the delimiter :/
<marler8997>
yeah, can't end strings with <
<ifreund>
actually I don't think that's ambiguous
LewisGaul has joined #zig
<ifreund>
just keep looking for the next < until you find another character, then subtract the number of >s at the start
<marler8997>
huh?
<ifreund>
I think since < is a special character too, >>foo<< could be "foo" and >>foo<<< could be "foo<"
<marler8997>
oh I see, you keep going while you see <
<ifreund>
during parsing don't stop after finding N closing delimiters, instead count how many consecutive <s are found and subtract N where N is the number of >s
<marler8997>
I see now
<marler8997>
ok, so the current idea is "..." and >>>...<<<
<marler8997>
we have 2 methods, increasing delimiter count, or custom delimiters
<ifreund>
I'm not sure we need "..." tbh, only reason to have it is if >foo< is too jarring for people used to "foo" strings
<marler8997>
oh right
<ifreund>
>>>...<<< solves all use cases IMO
<marler8997>
so we only need ><
<marler8997>
say we did that, what would you think about multiline?
<ifreund>
I don't think line breaks in the source cause any issues there, we could allow them
<marler8997>
so we could solve all the issues with ><
<marler8997>
but compare that to "..." and @"""..."""
<ifreund>
one issue with that is you need a way to escape "
<ifreund>
and @" doesn't work
<ifreund>
>< would require @> and @< but they wouldn't cause issues
<marler8997>
we could go back to "..." and @"X...X
<ifreund>
or "..." and @```...```
<marler8997>
how is @```...``` different from @"""..."""?
<ifreund>
you can use @" to escape "
<marler8997>
oh right
<marler8997>
@>>><<<
<marler8997>
there's that one too
<marler8997>
"..." and @>>>...<<<
<ifreund>
Is there a downside to just >foo< >>>...<<< other than the strangeness factor?
<marler8997>
@>>hello this is a coo! string with <xml> tags and stitch @>strings< as well<<
<marler8997>
more reserved characters
<ifreund>
I guess if you want to use @< and @> for comparison operators there's a conflict there too
<marler8997>
true
<marler8997>
those are not planned right now though
<marler8997>
$eq $lt $gt are the plan at the moment
<marler8997>
I mean @eq...
<ifreund>
sounds fine to me, @lt and @gt feel better than @< @> to me because of the prefix
<marler8997>
How often do we think someone will use >...<?
<ifreund>
I think strings will mostly be used to pass arguments to programs
<ifreund>
or to output formatted text
<ifreund>
really I think we'd need to translated some of the example code and see how it looks
<marler8997>
ok, I think at this point we need to write down the options and come back to this
<marler8997>
I'm going to create an issue in the repo and enumerate them
<ifreund>
cool, I'll take a look and comment with anything I think is missing
<ifreund>
(I wonder if we should have a #stitch channel, this is a lot for #zig...)
<marler8997>
this is the second time we've taken over the Zig channel, it might be time for that as at some point too much discussion is probably rude
<ifreund>
#stitch is free
<marler8997>
let's do it
_whitelogger has joined #zig
podge has quit [Quit: quit]
emptee has joined #zig
eax has joined #zig
eax has quit [Remote host closed the connection]
bitmapper has joined #zig
emptee has quit [Remote host closed the connection]
nycex has quit [Remote host closed the connection]
nycex has joined #zig
Akuli has joined #zig
waleee-cl has joined #zig
Techcable has joined #zig
LostKobrakai has joined #zig
LostKobrakai has left #zig [#zig]
LostKobrakai has joined #zig
Techcable has quit [Quit: Leaving]
LostKobrakai has left #zig [#zig]
Techcable has joined #zig
LostKobrakai has joined #zig
<LostKobrakai>
Hi, I'm new to zig and working with a C library expecting a const char *iban. How would I be creating that in zig?
<ifreund>
"foo" would be one way
<ifreund>
what data are you trying to pass?
<ifreund>
assuming the C code expects a 0 terminated pointer, the equivalent zig type would be [*:0]const u8
<LostKobrakai>
When I try a literal string I get this error: error: expected type '[*c]const u8', found '[]const u8'
<ifreund>
the type of "foo" is *const [3:0]u8, so I'm assuming you are doing something to coerce it to []const u8 before passing it to C
Swahili has joined #zig
<LostKobrakai>
yeah, I'm passing it into a function and that's the type I assumed it would be
<LostKobrakai>
can I use a different type in the functions parameter?
<ifreund>
indeed, you could use [*:0]const u8
<ifreund>
which is a 0 terminated constant pointer to u8
<LostKobrakai>
with this I get errors of ld.lld about my C libraries functions being undefined symbols
<g-w1>
how do you link it?
<ifreund>
how are you building?
<LostKobrakai>
I don't have the source, but a lib.a and lib.h file, which I copied into a folder and include that in zig
<g-w1>
you need to link lib.a
dyeplexer has quit [Remote host closed the connection]
<LostKobrakai>
Thanks. Seems to work now, but also interesting that I didn't seem to have hit this before at all
<Gliptic>
presumbly you weren't actually calling anything in the library until now
<Gliptic>
*presumably
haliucinas has quit [Quit: Lost terminal]
haliucinas has joined #zig
<v0idify>
line 768 at std/event/loop.zig says: @compileError("TODO: integrate timers with epoll/kevent/iocp for single-threaded"); how would this (timers through epoll) be implemented?
LostKobrakai has quit [Quit: LostKobrakai]
LewisGaul has joined #zig
neptunepunk has quit [Ping timeout: 272 seconds]
<mikdusan>
regarding the llvm12 `sret` issue, now that we have the lemon-fix in place, are **ALL** `sret` to be using parens? I see a ton of `sret %0` or `sret %8` style in the code
<mikdusan>
andrewrk: ^^
<mikdusan>
because I just ran into the same gen llvm-ir, run it through llc and it complains about expecting '('
<mikdusan>
my ir is actually a mix. some `sret(...)` and some not
neptunepink has joined #zig
TheLemonMan has joined #zig
Swahili has quit [Remote host closed the connection]
kenran has joined #zig
kenran has quit [Remote host closed the connection]
kenran has joined #zig
emptee has quit [Quit: Konversation terminated!]
hnOsmium0001 has joined #zig
riba has joined #zig
qbit has joined #zig
<qbit>
hio!
<mikdusan>
so hunting 1 bug I find another. and boom, lemon engages and they've found an upstream bug: #6408
_whitelogger has joined #zig
kenran has quit [Quit: leaving]
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
gpanders has quit [Ping timeout: 268 seconds]
gpanders has joined #zig
cole-h has joined #zig
leon-p has quit [Quit: leaving]
<LewisGaul>
Hey all, I'm trying to build zig master branch for the first time (WSL1 Ubuntu) and cmake is failing with:
<LewisGaul>
-- Could NOT find clang (missing: CLANG_LIBRARIES CLANG_INCLUDE_DIRS)
<LewisGaul>
-- Could NOT find lld (missing: LLD_LIBRARIES LLD_INCLUDE_DIRS)
<LewisGaul>
and then failing to find libpthread. Are the above errors the first thing to fix? I have installed clang/llvm/lld 11. Any ideas?
xackus_ has quit [Ping timeout: 245 seconds]
midgard has quit [Read error: Connection reset by peer]
midgard has joined #zig
<mikdusan>
LewisGaul: I have no exp with WSL1 but have you have installed "llvm-11", what about "llvm-11-dev" ?
<LewisGaul>
I have indeed - I'm hoping WSL1 won't be a factor but annoyingly it is sometimes... May end up switching to try native windows I guess
<mikdusan>
and maybe libclang-11-dev, liblld-11-dev
riba has quit [Ping timeout: 245 seconds]
<LewisGaul>
Didn't have them, trying installing them
<LewisGaul>
I'm suspicious that I have /usr/lib/llvm-11/lib/libclang-cpp.so.11 but Findclang.cmake doesn't seem to look at that path?
<mikdusan>
needs header files (include/) too
<LewisGaul>
nvm installing the suggested packages seems to get cmake to succeed, thanks :)