ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
zesterer has quit [Quit: zesterer]
jdufault has quit [Read error: Connection reset by peer]
<jacobdufault>
Are the ':' between variable names and types used to resolve parsing ambiguities? Playing with go a little, it is very nice to just type 'a int' instead of 'a: int'
<jacobdufault>
I'm also hit pretty frequently by the fact that funcs do not have a ':' before the type, but variables do
<jacobdufault>
just feels a bit inconsistent
<andrewrk>
jacobdufault, no, the ':' is not necessary according to syntax
<andrewrk>
sorry, I mean it's not necessary to have unambiguous grammar
<andrewrk>
you mean functions do not have a ':' before the return type?
cenomla has joined #zig
steveno_ has quit [Remote host closed the connection]
<jacobdufault>
yea, ie, fn(a: i32, b: i32) i32 {}
<jacobdufault>
and also `var a: i32 = 0`
<jacobdufault>
versus `fn(a i32, b i32) i32 {}`, `var a i32 = 0;`
<jacobdufault>
dropping the `:` makes it much, much more pleasant to type
<jacobdufault>
(I'm also a huge fan of the proposal to drop the () from if/while/etc, though the required `.` is a bit unusual)
<MajorLag>
for the record, I am against both of those things on readability grounds.
<andrewrk>
I think most people prefer the : and bringing -> back
<GitHub196>
zig/master 6b5cfd9 Andrew Kelley: turn assertion into compile error for using var as return type...
<jacobdufault>
Well, the reason not having `:` is nice is because you don't have to hit a keyboard combo as often. I understand the readability concerns, but I wonder if that is something that will fade as you get used to reading code in the other style.
<MajorLag>
Because of type inference, I don't find it comes up that often. Actually I end up typing `var a = i32(0);` more often even though it's a whole extra character.
<andrewrk>
being easier to type has not been something that zig optimizes for. in general zig is happy to trade ease of writing code quickly in exchange for less bugs, lower maintenance cost, easier for a person to quickly read understand a piece of code they have not seen before
<jacobdufault>
yea, that is nice. I'm just not sure `:` is mkaing it easier to understand code. But enough bike-shedding, andrewrk: how hard would it be to add a mode to the zig compiler where it dumps a fully typed AST to say, json? ideally the compiler would not emit code and bail after AST creation
<jacobdufault>
the ast would also need to have locations back to source code
<jacobdufault>
if that's somewhat feasible, then I can write a backend for cquery, which will give things like cross references, goto definition, call hierarchy, etc
<andrewrk>
that would be great
<jacobdufault>
Depending on how fast ast creation is, I may also be able to do code completion - though that is harder and tbd
<andrewrk>
real quick on the syntax: I'm open to all these ideas. the problem is that it's difficult to please everyone. everybody has their own preferences about what looks good. so I try to make sure the semantics are helpful, and then not worry too much about the coat of paint on top
<jacobdufault>
a BFDL is always good :)
<andrewrk>
I'm excited about a zig cquery backend
<andrewrk>
there's 2 approaches we could take to this
<andrewrk>
1. add support for this to the c++ compiler, which already has type information
<andrewrk>
2. work on this in the self hosted compiler, which currently only is able to build an AST, and does not understand all the syntax yet
<andrewrk>
(2) is obviously the long term best solution, so the question is, should we do (1) right now?
<GitHub50>
zig/master d96dd5b Andrew Kelley: fix missing compile error for returning error from void async function...
<jacobdufault>
yep, so I'm curious how hard it would be to do (1)
<andrewrk>
I think it would be pretty straightforward
<andrewrk>
here's what we would have to change: 1. add code to append types that are created into a list. 2. after analysis, iterate over this list and render the types to json. all the information is available at this point
<andrewrk>
oh, we want an AST with types
<andrewrk>
how does cquery handle templates?
<andrewrk>
or rather, how would you want to handle functions in zig with comptime parameters?
<jacobdufault>
unique identifier is good enough, so long as function calls can be associated with that unique identifier
<jacobdufault>
templates are a bit messy, but they mostly work. if you have template specializations things break
<andrewrk>
zig does not have overloading, so I think there is no equivalent of template specialization
<jacobdufault>
if the template is truly untyped, iirc there isn't a whole lot to do (though cquery may find a specialization and use definitions from that - another contributor has worked on template indexing)
<andrewrk>
but what I mean is that if you have this: fn foo(comptime T: type) void { var a: T = undefined; // @typeOf(a) could be anything
<jacobdufault>
well, comptime function generation is a bit like template specialization
<andrewrk>
what we could do is have each AST node have a *list* of types associated with it
<andrewrk>
if that list is size 1, then you know the node is always that type
<jacobdufault>
if you emit a reference to that T, cquery will handle it fine. so multiple types have references to the same location
<jacobdufault>
might be a bit wonky, I'm not sure what the best behavior is
<andrewrk>
it used to be that nodes had types in them, but it made less sense with compile time function execution and generics
<andrewrk>
we could still try to emit data that would be useful to cquery
<jacobdufault>
can you post some example json for what you think the output would look like? that'd probably be easiest for me to tell if it will be workable
<jacobdufault>
I haven't looked too closely at zig compiler internals (yet) :)
<jacobdufault>
vim integration isn't great since it is challenging to extend the UI
<jacobdufault>
vscode
<jacobdufault>
there are plugins for vscode, emacs, vim, atom, kakoune
<jacobdufault>
re the json, it'd be simpler if the typeKind was inline, but otherwise looks good. If you're concerned about size cquery sometimes serializes things as trings, ie, positions are "100,30" instead of { "line": 100, "column": 30 }
<andrewrk>
those adjustments sound fine to me. you think the function body can be utilized?
<jacobdufault>
ideally the type declarations also include location
<andrewrk>
ah yes we have location for most type declarations (except primitive types)
<jacobdufault>
no location is fine, just jump to definition/etc will not work for them
<jacobdufault>
cquery would also need function call locations to do the more interesting things like call hierarchy
<andrewrk>
one of the "instruction"s in the body would have a kind/id that would be a function call
<jacobdufault>
then that sgtm
<jacobdufault>
writing an indexer should be pretty straight-forward
<andrewrk>
neat
<jacobdufault>
(from cquery's side)
<jacobdufault>
one thing that might be useful for performance: only dumping nodes from a specific file
<jacobdufault>
ie, if only foo.zig changed, we don't need everything from std
<andrewrk>
that makes sense
<jacobdufault>
btw, any idea on timeline for when this could be added to zig compiler?
<andrewrk>
jacobdufault, estimating a timeline. that's tricky :)
<andrewrk>
I will work toward it in the self hosted compiler
mal``` has quit [Ping timeout: 240 seconds]
mal`` has joined #zig
<andrewrk>
jacobdufault, what you can do is file an issue and I will schedule it in a milestone
<andrewrk>
and then you can see what other issues are in the earlier milestones
<jacobdufault>
okay, I'm gonna play around with adding it myself :)
<jacobdufault>
I haven't hacked on a compiler itself since college, so it'll be fun, hehe
<andrewrk>
fun :)
<andrewrk>
feel free to ask for guidance around the source code
<jacobdufault>
sure, any thoughts on how to integrate into the compiler?
<jacobdufault>
ie, zig json, or zig build-exe --json, etc
<andrewrk>
a new command would probably be easiest. the closest command to look at would be build-obj
<andrewrk>
you could set a flag on the CodeGen struct in main.cpp, and then in codegen.cpp::do_code_gen you could check for the flag, and instead of outputting machine code with llvm, output the json
<jacobdufault>
I wonder if I should do it as a flag to support the various build* commands
<andrewrk>
pros: that would allow you to do it simultaneously with a build. cons: not clear how it would work to only output data for 1 file
<jacobdufault>
`zig build --emit-json [file]`?
<jacobdufault>
Well, for the time being I can do a command. easy to change later
<andrewrk>
how it will eventually work - but we're far from this point - is it would be a --emit-json flag, and there would be a --watch parameter, and the compiler would watch source files for changes, keeping the json as well as the output binary up to date, with minimal work
<jacobdufault>
fyi: cquery assumes it will invoke the compiler
<andrewrk>
noted
tiehuis has joined #zig
<tiehuis>
made some pull requests to add zig support to some line-counting tools:
<andrewrk>
hmm we definitely still have null literals
<andrewrk>
I think those ones are empty so we don't access any fields
<jacobdufault>
grepping doesn't reveal it either
<jacobdufault>
ah, right
<andrewrk>
that's a pretty nice tool
<jacobdufault>
yea, I got frustrated with how bad c++ tooling was
<jacobdufault>
actually most dev tooling isn't very good :/
<jacobdufault>
oh well
<jacobdufault>
cquery isn't perfect either
<andrewrk>
c/c++ don't make it easy
<jacobdufault>
but hopefully a step in the right direction :)
<jacobdufault>
yea, cquery relies heavily on libclang
<jacobdufault>
the main innovation of cquery is that it is fast
<jacobdufault>
much, much, much faster than anything else
<andrewrk>
speed is a wonderful feature
<jacobdufault>
just curious, did you grab buffer.hpp from a different/older project? it seems to be written in much more so of a c-style
<andrewrk>
almost all of zig is in a C style
<andrewrk>
if it weren't for llvm/clang we wouldn't even link against libstdc++
<jacobdufault>
I mean, compared to ZigList
<andrewrk>
ah
<jacobdufault>
the code is very readable, btw
<andrewrk>
thanks :)
<jacobdufault>
AstNodeWhileExpr and friends have `Buf *name` style variables - are these variable declarations expressed elsewhere in the ast?
<jacobdufault>
ie, how do I figure out the type of `name`
<andrewrk>
the name is non-null if the while is unwrapping a nullable, like this:
<andrewrk>
while (foo()) |value| { }
<andrewrk>
name would be "value"
<andrewrk>
so if @typeOf(foo()) is ?T then @typeOf(value) is T
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<andrewrk>
after a compilation, every function will have a list of basic blocks and IrInstructions in theme
<andrewrk>
one idea is that you could iterate over these, looking for IrInstructionIdDeclVar
<andrewrk>
if you find one whose source_node is NodeTypeWhileExpr then you've found your type
<jacobdufault>
hmm, currently I was playing around with iterating the ast similar to `ast_render.cpp`, but as I'm looking more closely type information might not be available
<andrewrk>
it's not available, because 1 AstNode might have N types, after generic instantiation
<andrewrk>
I think this is called mono-morphisation
<jacobdufault>
ah, fun fun
<andrewrk>
but you do have a mapping of IrInstructions back to AstNode
<andrewrk>
so you'd kinda like hover over a generic function, and cquery might have to say: this variable is one of these types: [x, y, z]
<andrewrk>
I mean, however you want to represent it, that's what the data is
<jacobdufault>
heh, at the moment cquery would just pick one
<jacobdufault>
since it isn't a common case for C++, but that could be improved
<jacobdufault>
it seems like there are quite a few instances where `AstNode` can only be one type; have you considered making an `AstNode<T>` class which only stores an instance of that type?
<jacobdufault>
(I can see a good argument against fwiw in the sense that it doesn't quite follow c)
<andrewrk>
I think instead of that pattern it would follow the IrInstruction pattern, with the `base` field
<andrewrk>
poor man's OOP
<andrewrk>
that's how it works in the self hosted parser
<jacobdufault>
How can I get the globally unique name for the function, ie, the name used in the object file? USR in C++
<andrewrk>
I believe that is FnTableEntry::symbol_name
<jacobdufault>
Okay, how does that compare to llvm_name?
<jacobdufault>
FnTableEntry::llvm_name
<andrewrk>
I'll describe status quo, with the understanding that maybe status quo should be changed:
<andrewrk>
the logic is in codegen.cpp::fn_llvm_value
<andrewrk>
it tries to use symbol_name. if it's an external function or an exported function, it's guaranteed to be unique otherwise we would have gotten a compile error
<andrewrk>
next we mangle the name by adding ".%d" where %d is a number that increases until we find a name that does not conflict with something we're trying to export, or an external function name
<andrewrk>
(that mangling happens only if necessary)
<andrewrk>
finally we add the function to the llvm module, where llvm may further mangle a name, if it conflicts with another non-exported, non-extern function
<andrewrk>
then we ask llvm what name it chose, and that's `llvm_name`. so `llvm_name` is the actual thing that goes into the object file
<andrewrk>
and we only find out about llvm_name after codegen completes, so you'd have to read the value *after* do_code_gen
<andrewrk>
I think symbol_name should be ok though, unless you're doing something with the object file. symbol_name is what the user wants the symbol to be
<andrewrk>
but it might not be unique
<andrewrk>
if you need a unique ID for the function that is not user-visible, use the pointer address
<jacobdufault>
the unique ID needs to be stable across invocations
<andrewrk>
I see
<andrewrk>
I've been thinking about having the concept of a canonical "path" to a given declaration from the root source file
<andrewrk>
something like `std.os.path.join`
<jacobdufault>
that'd probably do the trick
<andrewrk>
stable across invocations is an interesting problem
<andrewrk>
how about: file path + symbol_name ?
<jacobdufault>
clang does mangling, which includes file path if the symbol is local to only that file
<jacobdufault>
but since c++ has forward decls public symbols do not include the file
<jacobdufault>
I think the logic is pretty complicated. It results in huge strings
<jacobdufault>
the constraint is that if the two symbols refer to the same object, they need to have the same identifier; if file path + symbol_name accomplishes that then sg, but does zig have any sort of forward decls?
<andrewrk>
aha, in that case file path + symbol_name is correct for most functions. you could check if a function is exported and in this case omit file path
<andrewrk>
no forward decls. all zig functions are known to the compiler at compile time. top level declarations are order-independent
<jacobdufault>
:)
davr0s has joined #zig
_whitelogger_ has joined #zig
Hejsil has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
tiehuis has quit [Quit: WeeChat 2.0.1]
SimonNa has left #zig ["Leaving"]
hoppetosse has joined #zig
steveno_ has joined #zig
IntoxicatedHippo has joined #zig
davr0s has joined #zig
<IntoxicatedHippo>
Does zig have some kind of introspection for structs? I want to make something to parse JSON in to structs using the structs member names/types, similar to this: https://github.com/google/gson
<MajorLag>
Thanks. I'm planning to use something like that eventually to do automatic generation of serialize/deserialize functions for structs. That has the potential to save a lot of tedium.
Ichorio has joined #zig
<MajorLag>
andrewrk: looking over this old introspection code, it occurs to me that it might make more sense to have a single builtin @TypeInfo or something that returns a struct representing all this information.
Hejsil_ has joined #zig
jfo has joined #zig
davr0s has quit [Ping timeout: 256 seconds]
Hejsil_ has quit [Read error: Connection reset by peer]
jfo has quit [Quit: WeeChat 1.9.1]
<andrewrk>
MajorLag, I think you're right
<andrewrk>
Hejsil, nice semicolon fix :)
jjido has joined #zig
davr0s has joined #zig
<MajorLag>
andrewrk: translate-c uses @"" for anonymous structs in unions, but if there are 2 anonymous structs in a union this results in a collision.
<andrewrk>
MajorLag, I think it's a mistake to use the empty string as an identifier. I think that's an oversight
<andrewrk>
we should translate anonymous structs to anonymous structs
<andrewrk>
I think this is because we didn't use to have anonymous structs, and now it can be improved
<MajorLag>
that would complicate accessing the members, you'd have to look at what translate-c generated to see which member ended up in which dummy
<andrewrk>
what do you mean? they're just normal fields with the names DUMMYSTRUCTNAME and DUMMYSTRUCTNAME1, right?
<andrewrk>
isn't that how you would have to access these in C too?
<MajorLag>
in the original C, I could `theStruct.lMinimum` directly. IIRC, in zig I'd have to `theStruct.DUMMYUNIONNAME.DUMMYSTRUCTNAME.lMinimum`.
<andrewrk>
I see
<andrewrk>
I don't think we will have that namespace flattening feature
<MajorLag>
yeah, and for any other case I'm not sure it's even desirable. But here...
<andrewrk>
here it's a weird interaction with an awkward API. you can use a helper function to make it nicer if you want
SimonNa has joined #zig
<MajorLag>
it'd be hacky, but maybe allow `_` as an identifier in extern unions to mean "this is anonymous and it's members share my namespace"
<andrewrk>
I'm reluctant to add that just to workaround this one situation
<MajorLag>
I don't blame you, but this kind of thing is rather common in C apis I'm afraid. Would this work the same way for @cImport? because in that case not matching the documented interface is more of an issue I think.
<MajorLag>
Oh, I see. Misunderstanding. It isn't an union, its a union of anonymous structs. This works in gcc with std=c89: https://paste.ubuntu.com/p/SQdZ6PvZ9w/
<andrewrk>
it's a gnu extension though
<andrewrk>
I mean, we don't have to get pedantic. I think the argument is less about what is a C standard and more about the tradeoff of making zig more complicated in exchange for handling this use case better
<MajorLag>
Ok, well, I stand corrected on the standard. GCC with -pedantic confirms your assertion. Either my memory is faulty, or the stuff I'm remembering just relied on GNU extensions. It might not be as big a problem as I originaly thought.
<MajorLag>
Is there a known workaround for the "depends on itself" false positive?
<andrewrk>
I can take a look at that right now
<andrewrk>
#624 right?
<MajorLag>
yeah, that one. though I think I may have found a different case, not sure if it is related.
<MajorLag>
The identifier being errored on is an extern function type, which takes a struct which has a member that is a union of a struct that has a member that's pointer type of the original type.
<andrewrk>
so there's no comptime function invocations?
<andrewrk>
that might be easier to solve than #624
<MajorLag>
I'll give you some code to work with, just a sec
Tobba_ has quit [Read error: Connection reset by peer]
steveno_ has quit [Remote host closed the connection]