08:54 <GitHub194> [zig] tiehuis pushed 1 new commit to master: https://git.io/vxJDP

08:54 <GitHub194> zig/master d6e84e3 Marc Tiehuis: Add WebAssembly output workaround for LLVM 6

08:54 <tiehuis> jfo: I added a workaround to master for that environment parsing issue when trying to get wasm output

08:55 <tiehuis> if you have llvm configured with the wasm backend then you shouldn't need any extra configuration

08:55 <tiehuis> i'll also enable that backend in the docker image so you won't necessarily have to do a full compile yourself

08:56 <tiehuis> will get that pushed to docker hub tomorrow when i re-compile

09:05 <jfo> tiehuis: cool! I'm looking forward to working on that more in the near future

09:07 <tiehuis> awesome. I have to say, it's pretty great not needing emscripten/binaryen and all that to do compilation

11:02 <jfo> yeah... I'm really interested in how webassembly will develop. I have always been interested in it but every time I have given it a try I've been immediately confounded by the massive emscripten output, I just couldn't understand why I couldn't simply compile an object file and load it into js land

11:03 <jfo> of course that was always possible, but emscripten is heavy because it's polyfilling the stdlib and building all sorts of bridges back to the browser api

11:04 <jfo> I really want to write about this because I feel like wasm in its current form is very confusing to most people... it's really interesting and powerful but there are significant implications about library compatibility and the runtime etc that are really lost in the shuffle

11:36 <jfo> but of course I have to fully understand it myself first :)

13:55 <MajorLag> andrewrk: it looks like my issues with comptime error handling were either me doing something wrong when I was debugging or they were fixed with the other comptime patches. There is some strange @compileLog() behavior related to comptime loops, but I'm not entirely sure it doesn't make sense in some way I'm not clear on. I'll post an issue regardless.

14:49 <MajorLag> actually, I think this is expected. Does this make sense to you: when @compileLog is encountered in comptime in a function, we stop executing once we exit that function?

14:50 <andrewrk> MajorLag, I think I would need to see a code snippet to answer in a helpful way

14:51 <andrewrk> @compileLog does create a compile error, so it's quite possible that the compile error mechanism stops further analysis in some way

14:52 <andrewrk> my original intention would be that it would not modify analysis other than adding compile errors to prevent an actual build

16:02 <MajorLag> andrewrk: https://paste.ubuntu.com/p/Jp7nBJVKph/

16:03 <MajorLag> based on what you're saying, this isn't the expected behavior, so I should make an issue.

16:05 <andrewrk> let me consider this example for a few minutes

16:07 <MajorLag> ok. I notice that the results in that paste are slightly older than the code. I added the @compileLog("result: ", i); line.

16:31 <andrewrk> MajorLag, thanks for the example. I agree this is not expected behavior, and I understand what is causing it

16:31 <andrewrk> I have a lot going on today - I would appreciate a writeup. but I think the solution will be straightforward

16:32 <andrewrk> s/writeup/a github issue with this example code/

16:39 <Hejsil> Should we have some issue to improve error messages?

16:49 <andrewrk> Hejsil, sure. something in particular?

16:52 <Hejsil> Things like "try" in functions that doesn't return errors give you something like this:

16:52 <Hejsil> test "" {

16:52 <Hejsil> fn f() void {

16:52 <Hejsil> }

16:52 <Hejsil> f();

16:52 <Hejsil> const T = @typeOf(this).ReturnType;

16:52 <Hejsil> const K = @typeOf(this).ReturnType; // error: type '(block)' does not support field access

16:52 <Hejsil> }

16:52 <Hejsil> Ops

16:52 <Hejsil> Wrong paste

16:52 <Hejsil> Lol

16:52 <Hejsil> error: expected type '[]u8', found '@typeOf(Allocator_alloc).ReturnType.ErrorSet'

16:53 <andrewrk> ah yes we need a better error message for this

16:54 <Hejsil> This "expected x, found y" are rarely the most helpful error messages either :)

16:55 <andrewrk> one thing we could add is a note for each type saying "declared here" if it is a struct or other aggregate type

16:55 <andrewrk> oh, I have a framework started for making these error messages better

16:55 <andrewrk> that's the implicit cast failure error

16:55 <andrewrk> and I added code to make implicit cast failure return detailed recursive information on why the implicit cast failed

16:56 <andrewrk> but most of that information is unused and we just print "expected x, found y"

16:56 <Hejsil> Nice

16:56 <Hejsil> Well, I can imagine the error messages will get better

16:56 <andrewrk> it's currently used only for error sets, when an error set cannot be implicitly casted to another one

16:56 <andrewrk> then it explains which error codes are missing from the destination set

16:57 <andrewrk> the philosophy of the c++ compiler is "get it to work and make sure it's tested"

16:57 <andrewrk> the philosophy of the self hosted compiler is "make sure it's perfect before moving on"

16:58 <Hejsil> Self hosted is pretty hype

16:58 <Hejsil> Zig is soo much nicer that C++

17:01 <Hejsil> Isn't the "declarations make new scopes" legacy from when goto was a thing?

17:02 <Hejsil> Ooh wait, no.

17:02 <Hejsil> I just remembered reading the "declaration makes new scopes" in the goto thread

17:03 <Hejsil> But ofc, to introduce variables mid function, a new scope is required

17:16 <MajorLag> andrewrk: #832

18:03 <andrewrk> Hejsil, it makes sense even from a debug info perspective. consider that until you step over a given variable declaration, that variable should not be in scope yet according to gdb

20:10 <aiwakura> build is failing for me on MacOS

20:10 <aiwakura> could just be some weird stuff in my work machine

20:10 <andrewrk> aiwakura, master branch is passing on travis MacOS. is this the libxml thing?

20:10 <andrewrk> can you give more details?

20:11 <aiwakura> https://pastebin.com/EVdXbi8y

20:11 <aiwakura> lld build is failing actually. lol.

20:12 <andrewrk> can you do make VERBOSE=1 and pastebin the command used to compile COFF/Driver.cpp

20:13 <aiwakura> https://pastebin.com/jeyExnNj

20:14 <aiwakura> this is using clang 6, but fails with the same error with apple's clang

20:15 <andrewrk> you're using a different compiler to build zig as was used to build llvm/clang

20:16 <andrewrk> you have to use whatever homebrew used. which is apple's clang, which is giving the same error, correct?

20:17 <andrewrk> the error you pastebinned is looking at llvm 6.0.0 libc++. that's not the same libc++ that homebrew used for llvm/clang

20:17 <andrewrk> I think you need to delete your build folder, create a new one, and then make sure to run cmake with the same compiler that homebrew used

20:17 <aiwakura> let me try

20:17 <andrewrk> aiwakura, ^

20:18 <aiwakura> wait I know what's going on...

20:20 <aiwakura> I was cloning my fork which is not up to speed with master

20:20 <aiwakura> lame

20:27 <andrewrk> aiwakura, is it working now?

20:28 <andrewrk> jacobdufault, I'll try to get to your PR tonight. thanks for waiting. I've been busy the past couple days

20:29 <aiwakura> yeah it's working

20:29 <aiwakura> sorry ;)

20:32 <andrewrk> np, glad it worked out

20:39 <jacobdufault> andrewrk: no worries, thanks. The bit I'm confused about is why everything is unresolved

20:40 <andrewrk> jacobdufault, what's your test input? one thing to note is that zig has lazy evaluation of top level declarations

20:41 <andrewrk> so the declaration has to reachable from an exported top level decl or a test

20:41 <andrewrk> `zig json` would probably be interested in setting some flag to check all declarations regardless of whether they are referenced

20:47 <jacobdufault> yes, build-exe will correctly resolve the declarations though

20:47 <jacobdufault> the test input is the same as in the comment

20:53 <andrewrk> yeah and it should at least have declarations for standard panic since you didn't override it

20:53 <andrewrk> I'll have a look

21:05 <andrewrk> jacobdufault, I added a comment onto the PR, I hope this can unblock you

21:05 <andrewrk> let me know if you have any more questions

21:31 <aiwakura> andrewrk, isn't zig built with debug symbols by default anymore?

21:32 <andrewrk> aiwakura, the default mode of zig builds is Debug, which comes with debug symbols

21:32 <andrewrk> the default cmake build type of the zig c++ compiler is Debug, which comes with debug symbols

21:33 <andrewrk> what are you observing?

21:34 <aiwakura> gdb -ex=r --args zig build-exe main.zig

21:34 <aiwakura> can't step through the compiler code though

21:34 <andrewrk> macos?

21:34 <aiwakura> this is Debian

21:34 <andrewrk> it works for me. what cmake command did you use

21:36 <andrewrk> you can also try: readelf --debug-dump=info zig

21:36 <andrewrk> you should get about 15 million lines of output

21:36 <aiwakura> hahahha

21:36 <aiwakura> I'm using the default options

21:37 <aiwakura> rebuilding just to be safe

21:45 <aiwakura> it works now. oh well.

23:15 <GitHub103> [zig] andrewrk pushed 1 new commit to master: https://git.io/vxTas

23:15 <GitHub103> zig/master 7f7823e Andrew Kelley: fix casting a function to a pointer causing compiler crash...

23:17 <GitHub31> [zig] AndreaOrru pushed 2 new commits to master: https://git.io/vxTa4

23:17 <GitHub31> zig/master 2a6ad23 Andrea Orru: Merge branch 'master' of https://github.com/zig-lang/zig

23:17 <GitHub31> zig/master 2cdd50c Andrea Orru: Panic instead of segfault when returning generic type from functions...