00:00 <_0joshuaolson1> Thankfully, that won't be necessary. llvm-devel did get me Core.h, I just used 'find' wrong too... (sorry). Trying again.

00:02 <_0joshuaolson1> I double-checked - I applied the diff to the right file, and I have /usr/include/llvm-c/Core.h. Same output, though. I have CMake 3.10.1

00:02 <hopppetosse> andrewrk: would it be possible to have both release and debug builds for windows on appveyor?

00:04 <andrewrk> hopppetosse, the debug build of llvm+clang for windows is quite large

00:05 <andrewrk> I think if you need to debug zig itself, it's a fair requirement to build from source

00:05 <hopppetosse> true

00:09 <_0joshuaolson1> Let me try a paste bin this time to show my output: https://paste.ee/p/eU7eH

00:10 <_0joshuaolson1> Not including the logs, but I have them

00:13 <_0joshuaolson1> Maybe relevant: the problem is CLANG_INCLUDE_LIBS, not llvm

00:14 <_0joshuaolson1> Do you know a file I can check for that?

00:19 <_0joshuaolson1> Okay, sorry for taking your time. Installing clang-devel on Fedora does pull in Clang, but gcc was used as I wanted. I'll just make a tiny readme PR again and you can nit it there.

00:20 <_0joshuaolson1> *clang the compiler binary*

00:20 <andrewrk> _0joshuaolson1, ok the diff I gave you worked, and it found llvm headers. so we just need clang headers

00:20 <andrewrk> did clang-devel make zig's cmake output work?

00:20 <_0joshuaolson1> Yes, it does work now. But I reverted the diff and it also compiles correctly.

00:20 <andrewrk> oh.

00:21 <_0joshuaolson1> I'll just PR that the 'library' has to include headers (Fedora doesn't think so)

00:21 <andrewrk> just put the word "development" before "libraries"

00:23 <_0joshuaolson1> For LLD too?

00:25 <_0joshuaolson1> Thanks for your patience. PR 808. Have a good one.

00:25 <GitHub118> [zig] 0joshuaolson1 opened pull request #808: Clarify what is meant by 'libraries' (master...patch-1) https://git.io/vAHQ7

00:26 <GitHub187> [zig] andrewrk closed pull request #808: Clarify what is meant by 'libraries' (master...patch-1) https://git.io/vAHQ7

00:26 <GitHub179> [zig] andrewrk pushed 1 new commit to master: https://git.io/vAHQb

00:26 <GitHub179> zig/master c787837 Joshua Olson: Clarify what is meant by 'libraries' (#808)

14:31 <hoppetosse> MajorLag: I'm still getting that link error, even after specifying the libraries and stdcc

14:31 <hoppetosse> *stdcallcc

14:33 <hoppetosse> I did manage to create a smaller windows.h.zig with WIN32_LEAN_AND_MEAN after andrewrk pointed out I could use an intermediate .h file with all necessary declarations

14:33 <hoppetosse> only about 30k lines

14:39 <MajorLag> Odd. Are you on the latest artifact? That should give a more informative linker error

14:43 <hoppetosse> yep, latest artifact

14:44 <hoppetosse> unless I somehow downloaded the wrong one

14:44 <MajorLag> I'm still using the monstrosity I created without LEAN_AND_MEAN. I've got several hours into cleaning it up at this point. translate-c seems to be unaware that it can't cast between ints and pointers without @intToPtr and @ptrToInt, among about 1000 other little things, like missing macros, intrinsics, and some stuff that is used in assignments but doesn't seem to exist. There's about 140 extern functions that are

14:44 <MajorLag> I that don't actuall seem to exist in any library or dll.

14:44 <MajorLag> and you still just get "error: link error"?

14:45 <MajorLag> Also this is kind of hilarious, it translates `(3*4)` as `(&3)(4)`

14:45 <hoppetosse> hahaha oh my

14:46 <hoppetosse> I'll check my function signatures

14:48 <hoppetosse> actually, now it's error: link failed

14:49 <hoppetosse> With --verbose-link, I get something suspicious

14:49 <MajorLag> that's not much more helpful. Hmm... I wonder what's different? I'm not even linking against anything other than OpenGL that Zig doesn't link behind my back. My build script is just `zig build-exe main.zig --library "./OpenGL32.Lib"`

14:51 <hoppetosse> https://gist.github.com/raulgrell/f083a93c9a442c644177faf79d1aa1a7

14:52 <hoppetosse> I'm not linking with anything either

14:53 <hoppetosse> https://gist.github.com/raulgrell/6536362e0e2793fec04a888eae048350

14:54 <hoppetosse> That's the win32_lean

15:02 <MajorLag> strange... my --verbose-link is identical to yours (plus opengl). I invalidated my zig-cache just to be sure there wasn't something stupid going on there, still built fine.

15:02 <hoppetosse> I think I worked it out

15:03 <MajorLag> what parts of the API are you calling?

15:03 <MajorLag> oh?

15:03 <hoppetosse> It wasn't an issue with the windows api

15:03 <hoppetosse> it was something to do with linking with C

15:05 <hoppetosse> I tried to link it manually, and a few things stood out: I have spaces in the path to my libs, and at some point in my code I was using calloc

15:05 <hoppetosse> I'm not sure where it was going wrong, but I removed the --library c and the call to calloc and it built

15:06 <hoppetosse> also, the output command was lld ...

15:06 <hoppetosse> I had to call with lld-link

15:07 <hoppetosse> also, for some reason, the subsystem was console and not windows, but that fixed itself apparently

15:09 <MajorLag> my subsystem is console, and lld

15:09 <MajorLag> but I don't link with C

16:37 <hoppetosse> MajorLag: It's all working splendidly now, thanks for everything!

16:39 <andrewrk> hoppetosse, appveyor has multiple branches, I think you wanted to grab the llvm6 branch build

16:40 <andrewrk> MajorLag, hoppetosse, I've been slowly adding the important parts of the windows API into std.os.windows as well

16:40 <andrewrk> the nice thing about this is that it doesn't require h file parsing, and if you depend on them you automatically get DLL dependencies of kernel32.dll etc

16:41 <andrewrk> MajorLag, also, zig-cache isn't a cache yet :) it's just a temp folder where everything in it gets overwritten every time you run zig

16:41 <andrewrk> funny how nobody trusts it just because it has "cache" in the name

16:42 <andrewrk> (I don't blame you)

16:42 <andrewrk> computers have taught us not to trust caches

16:43 <hoppetosse> andrewrk: that's right, I got the wrong branch off appveyor

16:43 <hoppetosse> but it works on the other one, so I'm already happy

16:44 <hoppetosse> andrewrk: I noticed translate-c only chokes on a couple of things when using LEAN_AND_MEAN

16:45 <hoppetosse> An enum that has a negative and a hex literal that mess up when choosing the const type

16:51 <andrewrk> hoppetosse, if you collected a couple small examples and filed issues that would be very helpful

16:52 <hoppetosse> the only reason I haven't is that I'm running a release build and can't really file useful reports

17:08 <hoppetosse> andrewrk: do we still need a debug build of llvm-clang to make a debug build of zig?

17:42 <andrewrk> on windows, yes

17:44 <andrewrk> hoppetosse, why do you need a debug build to find examples of .h files that translate incorrectly?

17:47 <MajorLag> I wish I'd have kept notes on the things translate-c has botched so far, sorry. Offhand: it doesn't realize it needs to use @intToPtr/@ptrToInt, it doesn't know it can't (currently) @ptrCast to a nullable, it tries to negate a literal 0, it thinks (3*4) is a cast, it thinks (CONSTANT - 2) is a cast... lots of things with casting actually, C doesn't make it easy... it doesn't seem to understand 1234UL, it gives up

17:47 <MajorLag> say I blame it), and it set __FLT_EPSILON to 0.000000000 (doesn't handle scientific notation literals?).

17:47 <hoppetosse> I don't need it to find them, but I do to debug them

17:48 <hoppetosse> It doens't handle multi-line macros very well

17:49 <hoppetosse> I'll make issues for the ones that stood out to me

17:50 <andrewrk> ah I see

17:50 <MajorLag> Still, it did pretty well on windows.h considering how monsterously huge it is and how much weird crap it does.

17:51 <andrewrk> MajorLag, thanks! most of these are fixable

18:19 <hoppetosse> andrewrk: should I make a separate issue for each translate-c failure?

18:21 <andrewrk> hoppetosse, yes please

19:38 <andrewrk> hoppetosse, thanks for the writeups

19:40 <hoppetosse> pleased, I'm just trying to track down a couple more

19:43 <MajorLag> Is there a known issue: comptime struct cannot self-reference?

19:46 <andrewrk> MajorLag, is it this? https://github.com/zig-lang/zig/issues/624

19:47 <MajorLag> No, this is a "use of undeclared identifier" error.

19:48 <MajorLag> https://paste.ubuntu.com/p/H3Hdp523wP/

19:54 <MajorLag> andrewrk re: issue 810: @typeOf(2147483648) is a literal, so we'd end up at the else clause right?: c_int(2147483648) should be an error since max of signed int32 is 2147483647. Unless there's some trickery with c_ types I'm missing.

19:54 <andrewrk> MajorLag, I'm not able to work on it at the moment - can you make an issue for the self-reference thing?

19:54 <andrewrk> duplicate issues are no big deal

19:55 <andrewrk> what's happening in the C code? is it truncating?

19:58 <MajorLag> it's bitcasted. -2147483648

20:00 <andrewrk> ah I see

20:00 <andrewrk> we'll add logic in the generated code from the macro parsing for that

20:03 <andrewrk> MajorLag, thanks

20:30 <hoppetosse> The new pointer reform will be good for translate-c

20:30 <andrewrk> what in particular?

20:31 <andrewrk> pointer arithmetic?

20:31 <hoppetosse> I'm often running into trouble with flexible array members

20:31 <hoppetosse> struct with the last field being a pointer representing an array of runtime defined lenfght

20:33 <hoppetosse> I just think having a cleaner mapping between c and zig is going to help

20:36 <andrewrk> I think you're right

20:42 <hoppetosse> error: array access of non-array type is pretty pervasive

20:45 <hoppetosse> error: array access of non-array type is pretty pervasive

20:45 <hoppetosse> sorry, wrong window

22:01 <MajorLag> hoppetosse , if you or anyone else is ineterested, I wrote a comptime utf8 -> utf16 (no-BOM LE) function for use with windows.

22:22 <hopppetosse> I haven't needed it yet, but sure =)

22:34 <andrewrk> MajorLag, oh sweet, can you post that somewhere? we need that for #534

22:42 <hopppetosse> I haven't needed it yet, but sure =)

22:55 <andrewrk> MajorLag, let me know when your build starts taking > 1 second

22:55 <andrewrk> I need a bigger project to test out optimizations and caching :)