<merlyndmg>
oh I figured it out. if I make it a comptime variable and do a manual `if` on it then it works
<merlyndmg>
*parameter not variable
<merlyndmg>
that said, would it be silly for something like transCreateNodeBoolInfixOp to do an assert that you only passed it a booland or boolor operator? The original CPP code made such an assert. Does the function get auto-duplicated if you use compile time values, as long as they're not type variables and thus actually have to have different
<merlyndmg>
implementations?
<pixelherodev>
"if I make it a comptime variable and do a manual `if` on it then it works" ... definitely not going to steal that idea :)
<pixelherodev>
Also, regarding that LLVM backend thingy: I slowed down the VM and now it looks even cooler
<andrewrk>
frmdstryr, I'm definitely interested in working on the perf of stream server with regards to async and stuff, but there's a bunch of work to get to that point. I wonder if in the meantime you would be interested in looking into the perf of self-hosted parser
<andrewrk>
that's a very straightforward, blocking operation
<andrewrk>
even when we have threads, the task of parsing won't be split into threads
<andrewrk>
(perhaps 2 threads separately parse 2 files, but not 2 threads on 1 file)
<andrewrk>
and I'm sure that we're not at top speed for self-hosting parser, I think there is probably a lot of room for improvement
<andrewrk>
how the arena allocator works for one, as well as which list data structure to use (I doubt the current use of SegmentedList is the best choice)
<andrewrk>
and then maybe even some of the parsing code, idk
<mq32>
andrewrk: do you really want to tell me that zig can now again compile for AVR __after__ i coded my weekend project in C?! :D
<mq32>
*grin* next project it is, then... :)
frmdstryr has quit [Quit: Konversation terminated!]
protty has joined #zig
<daurnimator>
andrewrk: at this point... do you think streams as mixins will be accepted? I don't want to build too much more on top
<andrewrk>
the part where the namespaces conflict is a no-go
<protty>
andrewrk: hey, am here from the PR if youd prefer faster feedback
<daurnimator>
FWIW I actually consider the namespace conflict a good thing. I can't imagine wanting to do: myobject.something.read() *and* having myobject.someotherthing.read() and having 2 different results...
<mq32>
daurnimator: C# has a quite nice feature for "different implementation of a method with the same signature from two different interfaces"
<mq32>
interface A { void Foo(); } interface B { void Foo(); }
<mq32>
class C : A, B { void A.Foo() { } void B.Foo() { } }
<mq32>
whereas a normal implementation looks like this:
<mq32>
class C : A { public void Foo() { } }
<daurnimator>
mq32: if I have a `C`, how do I call them?
<mq32>
you have to explicitly cast into the interface
<mq32>
lemme test
<daurnimator>
mq32: for just the conflicting case? or the general case?
<daurnimator>
if just the conflicting case... I guess that's okay, but I think that people's tendency for defensive coding will make it a mess where people use it too much
<daurnimator>
if its the general case.... I don't get the ergonomics I'm after
protty has quit [Remote host closed the connection]
<daurnimator>
mq32: I'm a little confused with your example: could you show an example of an interface adding "helper" methods?
<mq32>
what is a helper method?
<mq32>
C# has only "pure" interfaces
<daurnimator>
e.g. base class implements `fn add(x) {}`, and now you want to add a `fn inc() { return add(1); }`
<mq32>
ah
<daurnimator>
--> the whole idea of "mixins" is to have a library of these wrappers that you can add to your object
<mq32>
i'll make an example
<mq32>
but keep in mind: C# can't do implementation of methods in templates
<mq32>
*interfaces
<daurnimator>
mq32: I think that's the whole point though: the question is: if you implement methods in interfaces/templates, then how do you handle collisions
<mq32>
c# doesn't allow the call then and requires an explicit cast
rjtobin has quit [Quit: Leaving]
<daurnimator>
mq32: how does that work with chaining?
<daurnimator>
mq32: e.g. what if an interface implements or requires another interface?
<mq32>
you can just use inheritance on interfaces
<mq32>
interface B : A { }
<mq32>
which will require all methods from A to be available when implementing B
<mq32>
extension methods in C# are quite powerful as well. you can even implement them on generics
ltriant has joined #zig
muffindrake has quit [Ping timeout: 250 seconds]
muffindrake has joined #zig
ur5us has quit [Ping timeout: 250 seconds]
return0e_ has joined #zig
return0e has quit [Ping timeout: 276 seconds]
adamkowalski has joined #zig
<adamkowalski>
What options do we have for sets in the standard library?
<daurnimator>
adamkowalski: std.HashMap(T, void)
return0e_ has quit [*.net *.split]
nullheroes has quit [*.net *.split]
traviss has quit [*.net *.split]
dddddd has quit [*.net *.split]
slice has quit [*.net *.split]
sammich has quit [*.net *.split]
Sargun has quit [*.net *.split]
wilsonk has quit [*.net *.split]
lupine has quit [*.net *.split]
tdeo has quit [*.net *.split]
shachaf has quit [*.net *.split]
dom96 has quit [*.net *.split]
programi1 has quit [*.net *.split]
<adamkowalski>
daurnimator: thanks! if I want to construct a set of items (but the items are already stored somewhere else) should I just store the pointers in the HashMap?
<adamkowalski>
Or if the struct is a union of u64 types just with different tags, should I store it by value?
<daurnimator>
depends on the lifetime of the items and the set...
<adamkowalski>
It is still a "primitive" type at that point right
<daurnimator>
what is?
<adamkowalski>
a union(enum) of many different u64 types
<adamkowalski>
the lifetime of the items is going to be longer then the lifetime of the set
<adamkowalski>
so storing pointers is not dangerous
<adamkowalski>
however a union will be the size of the largest member anyway right? so it will be 64 bits
<adamkowalski>
and a pointer will be 64 bits
<adamkowalski>
so it seems like it doesn't matter?
return0e has joined #zig
casaca has joined #zig
<daurnimator>
adamkowalski: if its a tagged union then it will be size of largest member + tag size
<daurnimator>
(+ alignment)
<adamkowalski>
Thanks! Speaking of tagged unions, is there something akin to if let in Rust?
<adamkowalski>
I know I can switch on the tag and then do something, but what if I only care about one case
<andrewrk>
what's the floating point operation called, that is "ceil" but always away from zero
<andrewrk>
`0.1 -> 2` `-0.1 -> -2`
<daurnimator>
andrewrk: towards infinities?
<andrewrk>
yes
<daurnimator>
that's what its called
<andrewrk>
ceil?
<daurnimator>
either "round_towards_infinity" or "round_away_from_zero"
<daurnimator>
"ceil" is usually taken to mean towards positive infinity.
<daurnimator>
i.e. `0.1 -> 2`, `-0.1 -> 0`
<daurnimator>
uh, `0.1 -> 1`
<daurnimator>
I assume you mean that before?
<andrewrk>
I want: 0.1 -> 1, -0.1 -> -1
<daurnimator>
yep that would be "infinity"
<andrewrk>
what libm function is that
<daurnimator>
there isn't one IIRC. round-towards-infinity isn't defined as an IEEE754 mode
<data-man>
C++ has nearbyint
<daurnimator>
usually the modes are: up, down, zero, near
<adamkowalski>
andrewrk: I'm having an issue with recursion. The compiler says it cannot resolve inferred error set: not fully analyzed yet
<daurnimator>
adamkowalski: recursive functions need to specify their error set
<adamkowalski>
Is there a way to query a function for it's error set? I should just be able to to look at all the functions I call try on and take the union of that right?
<daurnimator>
data-man: in C that's FE_TONEAREST
<andrewrk>
round is so close, but it's off by 0.5
<daurnimator>
andrewrk: do you have a usecase for this?
* daurnimator
thought you might have been asking for reasons of completion
<andrewrk>
yeah it's for the codegen of comparison operators between ints and floats
<andrewrk>
I'm working on merging the oldest open pull request
<andrewrk>
new language change: comparison operators (<, >, >=, <=, !=, ==) work on any combination of ints and floats, no type errors
<daurnimator>
sounds good. probably has some real funky edge cases!
<andrewrk>
especially with vectors
<andrewrk>
it's sound though, one can always answer the boolean question, regardless of the types
<adamkowalski>
this complains that field access is not supported
<adamkowalski>
Can I just query a hashmap directly? None of the error sets are listed in the source for hash map so it's hard to get that information haha
<andrewrk>
adamkowalski, give the function an empty error set, and let the compiler tell you the errors you need to put in there
<andrewrk>
this may be able to be improved in the future, inferred error sets of recursive functions
<adamkowalski>
andrewrk: you also said in one of your streams that we should start using the async functionality to make sure our recursive functions don't stack overflow right?
<adamkowalski>
Would that also apply to tail recursive functions?
<andrewrk>
daurnimator, that codegens as @as(i17, op1) <= @as(i17, op2)
<andrewrk>
assuming the operands are runtime known
<daurnimator>
andrewrk: okay; similar question: `@as(f32, 33554432) <= @as(u16, 33554431)`
<daurnimator>
uh, u32 on the right
<andrewrk>
I don't see how this question is different
<daurnimator>
andrewrk: because then I follow up with the question: what about `@as(f32, 3.4028234664e1038) <= @as(32, 0xFFFFFFF)`
<andrewrk>
there is a mathematically correct answer to this comparison, which is clearly `false`
<daurnimator>
yes mathematically its fine, but for codegen, wouldn't you need a branch before each comparison to check if the f32 is out of range of the integer before you try and convert it to an `i33`?
<daurnimator>
for a given pair like f32/u32 there are numbers in one range that aren't in the other; and vice versa
<andrewrk>
yes, I don't know how to codegen this without branching
<daurnimator>
It seems like a tricky problem to figure out how to do it with a minimal amount of branching: you'd at least need one for checking too large; one for checking too small; and one for the comparison itself?
<andrewrk>
yeah, I can tell you what it's going to do in stage1: error: TODO implement this
<daurnimator>
though even then you'd probably need to do a check for fractional amounts..... though maybe you can do something clever with subtraction there
casaca has quit [Quit: leaving]
<daurnimator>
but yeah: I was curious if you had figured out an elegant way to do it
<andrewrk>
nope, only the realization that according to the type system, it is sound to allow for any (numeric) types
<andrewrk>
which, I would argue, makes the language smaller. since it lets you do something that makes sense to be able to do
<andrewrk>
maybe some hardware has float/int comparison instructions, idk
<daurnimator>
you also can get lost in the realm of ULPs... e.g. when comparing an integer to a float, are you comparing it when the integer is converted to a float?
<andrewrk>
each value has a mathematical number that it represents; that is what is being compared
<daurnimator>
it doesn't though
<daurnimator>
floating point values essentially represent a range
<data-man>
andrewrk: What do you think about new std.search module? binarySearch, Bitap, etc.
<data-man>
And move to std.search some funcs from std.sort
<daurnimator>
from x-ULP/2 to x+ULP/2
<andrewrk>
daurnimator, I see your point
<daurnimator>
andrewrk: e.g. if I write `@as(f16, 4095)`, then it's == to `@as(f16, 4096)`
<andrewrk>
hmm that's a decent argument in favor of not allowing the comparison
<daurnimator>
you *can* still compare them though: @as(f16, 4096) is obviously <= @as(u32, 5000)
<daurnimator>
but only for certain values
<daurnimator>
or at least: if it's within 1 ULP.... the answer is "its complicated"
<daurnimator>
Hmm... if you convert both operands to floating point.... is it always correct?
<daurnimator>
I think yes; unless you get an infinity
<daurnimator>
`@as(f16, 4096) <= @as(u16, 4095)` should be: `@as(f16, 4096) <= @as(f16, @as(u16, 4095))` which is: `@as(f16, 4096) <= @as(f16, 4096)` which is `true`
adamkowalski has quit [Ping timeout: 265 seconds]
ltriant has quit [Quit: leaving]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 265 seconds]
<daurnimator>
andrewrk: ^
THFKA4 has quit [Ping timeout: 245 seconds]
<Snektron>
<daurnimator "I can't say I like rust's soluti"> You can already kinda do that with your mixin strategy
<Snektron>
Then you would create a wrapper type every time you want to use a method
<Snektron>
Ex Random(&rng).int(u2)
<Snektron>
Hm, i guess that is a lot more different that i thought
demizer has quit [Remote host closed the connection]
<andrewrk>
scientes, btw I took your proposal to make comparisons work for all integer types, about to push to master
<scientes>
cool
<fengb>
I'm actually really glad c"" is gone. I had thought that it returned c pointers, and inferred [*c] pointers were null terminated pointers
<Snektron>
hm
<Snektron>
i get segfaults when allocating too much stack
<leeward>
While I'm on the subject, is there a canonical way to implement an opaque data structure in Zig? I've got a C library that I'd like to replace, and it's built around passing opaque struct pointers around.
<Snektron>
@OpaqueType()
<andrewrk>
Snektron, zig doesn't yet have the ability to detect stack usage at compile-time and request more at startup, but that is planned
<leeward>
Snektron: Thanks!
<scientes>
const slice: [:0]const u8 = "hello";
<andrewrk>
Snektron, one problem I haven't quite worked out is what to do when we know we need a certain amount of stack space, but zig is not in charge of calling main()
<scientes>
ahh that is really clever
<scientes>
and it makes some of the stdlib work better on linux
<pixelherodev>
This is... weird
<pixelherodev>
That segfault I mentioned?
<pixelherodev>
Returning an error seems to trigger it...
<pixelherodev>
Rather, under specific conditions, *any* return seems to
<fengb>
It works and allows arbitrary yields along the entire stack
<pixelherodev>
Even @panic
<leeward>
Snektron: So if I want to export an opaque type in a generated header, I'll just "export const foo = @OpaqueType();"?
<scientes>
const slice: [:0]const u8 = "hello";
<scientes>
this also allows using null-terminated style with --release-small
<Snektron>
andrewrk, did you consider to add it to TypeInfo? if you still want to remove recursion, you could provide an @typeInfo(main).Fn.required_stack_space
<Snektron>
leeward, i think you're only allowed pointers to opaque types
<leeward>
Snektron: Oh, right, there should be a * in there.
<Snektron>
even with recursion, that value could be ?usize for required stack space
<andrewrk>
Snektron, it's not really part of the type; 2 functions with the same type could have different stack requirements
<Snektron>
depending on the invocation, yeah...
<fengb>
Could we annotate function pointers with max stack size?
<Snektron>
Thats another thing
<fengb>
(Should we?)
<leeward>
Snektron: Yeah, but that doesn't talk about generating header files. I need my library's users to have a name for the opaque type.
<andrewrk>
fengb, I think that will be a necessary component of eliminating stack overflow at compile time
<Snektron>
leeward, i think those OpaqueType's export just like normal types
<Snektron>
andrewrk, you could always have @requiredStackSpace(expr)
<fengb>
The only caveat to OpaqueTypes is that they can only exist as pointers and you can't dereference them, similar to forward declared structs in C
<Snektron>
thats alright when you export them
<leeward>
Snektron: Trying it
<Snektron>
btw, are promises still a thing?
<Snektron>
Because the documentation still lists them under TypeInfo
<leeward>
Is this a thing I can do, and if not, will it ever be?
<leeward>
Also, I'm guessing that my C API needs to have a bunch of functions that accept the opaque pointer type and @ptrCast it to the thing it's supposed to be, then call the function that actually does the thing with the pointer.
<pixelherodev>
I'd argue it should parse the signature and only the signature
<pixelherodev>
So you'd be able to determine that it returns Foo and takes no parameters, but it wouldn't evaluate the function itself
<andrewrk>
fengb, I think @typeInfo is going to stop having declarations in it
<pixelherodev>
If you only analyze the type of a function without calling it, there's no need to parse the function, and thus it shouldn't be parsed
<andrewrk>
something as drastic as removing decls isn't necessarily needed though. now that we have lazy values, they can be used to tackle this problem
<leeward>
Incidentally, am I right in assuming that I just don't have permission to add labels like `bug` to issues I raise and PRs I submit? I've seen other people add tags to my stuff, but I don't see an obvious way to do it myself.
<shakesoda>
leeward: yeah, github restricts that to people with write access to the repo etc
<shakesoda>
i think there might be a second permission level for it also, but not sure
<leeward>
shakesoda: Excellent. Just wanted to make sure I wasn't creating more extra work for people than I needed to.
mahmudov has joined #zig
dimenus has joined #zig
<andrewrk>
don't worry, the effort of labeling issues is nothing compared to the effort of actually solving the problem
<leeward>
Hmm, getting a link error with that printf example from before: lld: error: unable to find library -lC
<andrewrk>
if only zig could be improved, by futzing with labels all day :P
<shakesoda>
andrewrk: wouldn't that be a convenient alternate reality, lol
<andrewrk>
leeward, your `C` should be `c`
<shakesoda>
as a maintainer of various things i always rather preferred doing them myself anyway
<leeward>
Of course it should.
<leeward>
andrewrk: thanks
<leeward>
shakesoda: I understand that. Having no label is better than having wrong labels.
mahmudov has quit [Ping timeout: 265 seconds]
return0e_ has quit []
<fengb>
I thought about lazy values, but that could lead to non deterministic declarations
<fengb>
e.g. running type info later can yield different results
<andrewrk>
that's a good point
<andrewrk>
fengb, a non-disruptive small improvement would be to make lazy all the declarations though. so if you never accessed the decls field then none of them get poked
<andrewrk>
and accessing decls field would mean all get poked
<fengb>
Ah I see. That’d make sense
<fengb>
That should fix it for this formatting issue. Thanks
<andrewrk>
alright, oldest "ball-is-in-my-court" pull request is now in November
dingenskirchen has quit [Quit: dingenskirchen]
jjido has joined #zig
<dimenus>
andrewrk: how long have you been working on zig fulltime now? a year?
<andrewrk>
since 2018 Jun 07. there was another stretch of time before that, adding up to about 1 year as well
<dimenus>
still enjoying it?
<andrewrk>
yes
<andrewrk>
impatient for async I/O & self-hosted to be further along though
<Snektron>
i realize "writing large numbers" is quite ambiguous
_Vi has quit [Ping timeout: 246 seconds]
<pixelherodev>
This is odd
<pixelherodev>
If I don't catch the error and just exit the function calling the function for which codegen is failing, I get a completely different segfault
mahmudov has joined #zig
<Snektron>
hmm thats too bad, andrewrk
<mq32>
andrewrk, similar topic than number separators: would it be possible and reasonable to make zig fmt allow some alignments in declarations?
<mq32>
if one is writing matrices or similar, it's really hard to read them after a zig fmt removes all white space
<pixelherodev>
... or not. I somehow got an entirely different error without changing the code but at least I'm getting this one consistently now?
darithorn has joined #zig
<mq32>
i can swear that i haven't seen that working
<andrewrk>
pixelherodev, if you're trying to debug a crash in llvm, I recommend a debug build
<andrewrk>
there's probably a useful assert that you're not hitting otherwise
dingenskirchen has quit [Remote host closed the connection]
tines9 has quit [Ping timeout: 252 seconds]
<pixelherodev>
... I don't think I can afford to that anytime soon
tines9 has joined #zig
<pixelherodev>
It takes a lot of hours and battery life, and I'm w/o a charger for the rest of the day (I use a spare battery instead of a charger because it's easier to carry)
<pixelherodev>
Hmm
<pixelherodev>
I think I might be running into #3029 actually
<pixelherodev>
The stack traces are very very similar
mahmudov has quit [Ping timeout: 248 seconds]
<pixelherodev>
But it's not a simple inline for this time...
merlyndmg has quit [Ping timeout: 260 seconds]
<pixelherodev>
Huh
<pixelherodev>
Found a workaround for this
<pixelherodev>
It only happens when that return is inside of a while
<pixelherodev>
Using a boolean and returning outside the loop works
<pixelherodev>
I think my original suspicious of it being a nested loop issue was right
<pixelherodev>
I think the basic block in question is one of the conditional blocks for the innermost loop
<pixelherodev>
Furthermore, `break` in the loop causes the same issue, so it's not a return
<pixelherodev>
And it also only triggers *inside of the conditional*
<pixelherodev>
This is really odd
<pixelherodev>
I have `if (std.mem.eql) {...} else {return error / break / etc}` -> panic
<pixelherodev>
s/panic/segfault
<pixelherodev>
With `else {failed = true;} if (failed) {break / return error / etc` it works fine
<pixelherodev>
I think Zig is generating invalid IR
<pixelherodev>
Going to use `--verbose-llvm-ir` and see if I can figure this out
mahmudov has joined #zig
wootehfoot has joined #zig
<pixelherodev>
andrewrk, correct me if I'm wrong, but returning an error should not generate `ret void` in the IR?
<pixelherodev>
Ah, was looking in the wrong place
<pixelherodev>
Gah
<pixelherodev>
That error table is huge
<pixelherodev>
almost 5000 characters :(
<andrewrk>
if you don't use @errorName then it doesn't generate one
<andrewrk>
also there is optimization opportunity with error sets, not taken advantage of
<pixelherodev>
Switching to @panic made it far easier to trace
<pixelherodev>
Since it's just a global with the string, a global for the slice containing that string, and the call to panic using the second global
<pixelherodev>
There a LLVM cli program to validate a module?
<andrewrk>
probably opt
<pixelherodev>
... huh. I split out the breaking part into its own function to make the IR easier to analyze
<pixelherodev>
And the segfault vanished
<andrewrk>
it can sometimes be an in-memory-only problem
<pixelherodev>
No, I mean the normal compiler worked
<pixelherodev>
... I think it might be an error merging error sets?
lunamn has joined #zig
<pixelherodev>
Weirdly, the error isn't even in the IR corresponding to the changed code
<pixelherodev>
It's in the unchanged then branch
<pixelherodev>
huh. And removing the error return from there causes an entirely different segfault which occurs before the codegen stage :(
<pixelherodev>
weird. Removing the entire then branch causes the same thing.
<pixelherodev>
Some integer overflow
_Vi has joined #zig
doublex__ has joined #zig
doublex_ has quit [Ping timeout: 250 seconds]
<pixelherodev>
huh. A grep for `null operand` gives nothing in the zig src
<pixelherodev>
Am I to assume that's from LLVM?
protty has quit [Ping timeout: 260 seconds]
<pixelherodev>
... I have no clue how to really debug this...
<pixelherodev>
Or not
<pixelherodev>
Just remembered metadata exists :D
<pixelherodev>
Okay, so this seems to occur in a very limited set of circumstances: has to be a conditional inside of a nested loop with two different branches which either never return (e.g. panic) or return immediately
<pixelherodev>
There's an entirely *different* bug that occurs if I remove either branch of the conditional without making some other tweaks :P
<pixelherodev>
Importantly, the second bug only occurs if the *else* branch specifically has such a branch
<pixelherodev>
So, correction: the second bug doesn't occur if only the else branch is removed
* lupine
wonders about fuzz testing compilers with randomly generated programs
<pixelherodev>
Okay, here's another weird bit
<andrewrk>
lupine, you're assuming that finding bugs is the bottleneck. we have 247 open bug reports
<pixelherodev>
With `if (a) {} else { branch }`, segfault
<pixelherodev>
With `if (a) {} else if (!a) {branch }`, compiles fine
<lupine>
hehe
<pixelherodev>
There a way to specify that e.g. past contributors can set labels in issues they open?
<andrewrk>
there is not
<pixelherodev>
Or possibly create a team for new contributors that gives them very limited permissions - such as setting labels?
<pixelherodev>
Eh
<pixelherodev>
That's probably more work
<pixelherodev>
then just setting the labels manually :P
<pixelherodev>
Yeah, this isn't just a hyper-specific bug
<pixelherodev>
Plenty of other places I'm switching from debug.warnings to returning errors that are running into the exact same thing
TheLemonMan has joined #zig
<TheLemonMan>
pixelherodev, are you trying to narrow down a bug in the LLVM IR?
<pixelherodev>
No
<pixelherodev>
Codegen
<pixelherodev>
Zig compiler is producing invalid IR
<pixelherodev>
ziglang/zig#3925
<TheLemonMan>
hmm, are you using an inline for?
<pixelherodev>
Nope
<pixelherodev>
I know which issue you're referring to
<pixelherodev>
That was my first thought as well
<pixelherodev>
I suspect it might be the same issue though
<pixelherodev>
I'll look into the inline for tonight, but it's quite possibly the same issue
<pixelherodev>
An easy way to test: `zig build-exe ... --verbose-llvm-ir` 2>temp ; opt temp; rm temp`
<pixelherodev>
Pass in an inline for to that
<pixelherodev>
If you get a message about "expected value in address space, received <null operand!>" it's probably the same issue
<pixelherodev>
It gets more interesting - returning an error from the if statement works fine
<pixelherodev>
Adding a non-branching else condition works
<TheLemonMan>
oh, so the error comes from opt?
<pixelherodev>
No
<pixelherodev>
`opt` verifies the LLVM IR
<pixelherodev>
And detects that it's not valid
<pixelherodev>
Adding a branch *in the else* doesn't break the else
<pixelherodev>
The else still generates correctly
<TheLemonMan>
...so it's `opt` that raises the error
<pixelherodev>
No.
<pixelherodev>
zig will still segfault there.
<pixelherodev>
Because it's generating invalid IR and then trying to produce valid asm from it
<pixelherodev>
opt just tells you what Zig is doing wrong
<pixelherodev>
Well
<pixelherodev>
Okay I see what you meant
<pixelherodev>
The `opt` is what causes the error message to print, yes
<pixelherodev>
Anyways, I think I figured out the specific logic that's breaking it
<pixelherodev>
Adding in a branch in the else shifts the target of the if branch - at least *logically*
<pixelherodev>
But that reference hasn't been updated
<pixelherodev>
And is thus null
<pixelherodev>
Branch in the if doesn't cause the same problem, because that's calculated before its target is
ur5us has joined #zig
<leeward>
How does allowzero interact with optional pointers?
<leeward>
Should `var p: ?*allowzero u8 = undefined` be legal?
FireFox317 has joined #zig
<TheLemonMan>
yup, it's codegen'd as a *u8 and a i1 to store whether it's null or not
<pixelherodev>
Okay, so uh - with a file opened via openWrite, is there an equivalent to fflush I need to use?
protty34 has joined #zig
<pixelherodev>
Never mind.
* pixelherodev
smacks his head into a wall
<pixelherodev>
I was using the wrong file path :P
<TheLemonMan>
leeward, good catch, you've found a simple yet gnarly-to-fix bug :)
<leeward>
TheLemonMan: fun. Should I file it?
<protty34>
fengb: looks like its always for single-threaded release-fast but cant find the reason of failure. All tests (excluding [free|net|open]bsd) work fine locally through qemu & wine
<TheLemonMan>
leeward, sure thing, I have a one-line fix ready but I'm not 100% sure it's the right thing to do™ atm
protty has quit [Remote host closed the connection]
protty34 has quit [Remote host closed the connection]
protty has joined #zig
leeward has quit [Quit: Quit]
leeward has joined #zig
<pixelherodev>
What bug is this?
<pixelherodev>
Ah
<TheLemonMan>
protty, the windows build is slightly more informative as it exits with EXCEPTION_ACCESS_VIOLATION
waleee-cl has quit [Quit: Connection closed for inactivity]
ur5us has quit [Ping timeout: 245 seconds]
jokoon has quit [Quit: jokoon]
FireFox317 has quit [Ping timeout: 265 seconds]
ur5us has joined #zig
<frmdstryr>
protty34: Could you benchmark https://github.com/frmdstryr/zhp on your computer? Interested to see how it compares to the other results in your gist
<protty>
TheLemonMan: you're right, its definitely segfaulting, but looks like it does so without outputting the test binary in zig-cache + the core dump backtrace in gdb is stripped..
dimenus has quit [Ping timeout: 248 seconds]
<protty>
frmdstryr: sure, I can try it out
protty has quit [Remote host closed the connection]
<andrewrk>
it gets rid of the mem_slot thing, making all allocas the same, and gets rid of the differences in result locations between comptime code and non-comptime code
<andrewrk>
lots of regressions to fix before it can be merged tho
<TheLemonMan>
oh that sounds cool
<TheLemonMan>
less tests -> less regressions to fix -> faster turnaround!
<andrewrk>
lol
<andrewrk>
the next major blocker for self-hosted is async I/O in std. the next major blocker for that is getting std.fmt.format to work as an iterator rather than using a callback function, so that std.fmt.format doesn't ever have to be async
<andrewrk>
so that we can make std.os.write participate in async I/O
<TheLemonMan>
aand I'm done for today, gn everybody!
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]