stage2: error return traces

[Vexu]

Currently disabled on all targets because LLVM is being a dick and I'm too tired to fight it.

$ zig2 test test/behavior.zig -I test -fLLVM    -target aarch64-linux
LLVM Emit Object... 
inlinable function call in a function with debug info must have a !dbg location
  call fastcc void @builtin.returnError(%builtin.StackTrace* %0) #13
inlinable function call in a function with debug info must have a !dbg location
  call fastcc void @builtin.returnError(%builtin.StackTrace* %0) #13
inlinable function call in a function with debug info must have a !dbg location
  call fastcc void @builtin.returnError(%builtin.StackTrace* %0) #13
inlinable function call in a function with debug info must have a !dbg location
  call fastcc void @builtin.returnError(%builtin.StackTrace* %0) #13

Not that it was that useful anyways:

$ zig2 run a.zig
error: Foo
???:?:?: 0x20b078 in ??? (???)
???:?:?: 0x20b145 in ??? (???)

I tried to do as much as possible in Sema without touching parameters, if that is also desired it should be done alongside the begin_call/end_call change.

Closes #11259
Closes #11084

[schmee]

@Vexu does this PR solve #1923 as well?

[Vexu]

@Vexu does this PR solve #1923 as well?

No, currently this just matches stage1.

[andrewrk]

I'll do a second review on the error return traces implementation, but I want to block the merge solely on the basis of 61d25c6.

build.zig should not assume that there is a config.h file in an arbitrary directory called "build". The intended way that it works currently is if you run zig build from inside a build directory that has already been used via the cmake build process, then it will find config.h from there. On my machine, I have many build directories:

[nix-shell:~/dev/zig]$ ls build
build/              build-debug/        build-llvm13-debug/ build-release/      build-llvm14/

They each have a different config.h, and arbitrarily choosing build/config.h is incorrect.

As for the silent default, what I would expect is for it to search for LLVM via your system default prefix. I see that it is hitting these lines:

            // Here we are -Denable-llvm but no cmake integration.
            try addStaticLlvmOptionsToExe(exe);
            try addStaticLlvmOptionsToExe(test_stage2);

Looking at the implementation of these functions, I don't think there is anything to change. These are perfectly reasonable defaults for the case when one choosing to build from source without the cmake bootstrapping step. Indeed, this is the path we use for the CI as well as zig-bootstrap.

My suggestion for your workflow is to follow the official building from source instructions and execute the zig build commands from inside the appropriate cmake build directory, or to continue to use the -Dconfig_h option.

[Vexu]

Looking at the implementation of these functions, I don't think there is anything to change.

They do need a ZIG_PREFER_CLANG_CPP_DYLIB equivalent so I guess I'll implement that instead.

[andrewrk]

Will that actually improve anyone's workflow? For your case, you have a build folder from cmake, correct? Then the correct way to build is using that same information, using the cwd method or with -Dconfig_h. Package maintainers building a zig package will do the same thing. People using zig-bootstrap will use static libs and never have a use case for dynamic clang.

[Vexu]

Well, not currently at least, but if we end up ditching the bootstrap compiler of cleaned output of stage2 with cbe only then there would be no config.h?

[andrewrk]

Agreed - at that point the logic for integrating with system LLVM, Clang, LLD will become the business of build.zig.

[andrewrk]

Great work! I like how you were able to move some of the functions into userland.

I'm sorry for taking so long to review this. It's ready to be merged as far as I'm concerned.

[andrewrk]

This looks a little fishy. I think it's OK for now, but before this function gets copy+pasted into the other backends, let's look into moving this logic into Sema. Perhaps for a Module in which error return tracing is enabled, it can create a root reference to this type and store it directly in Module.

[andrewrk]

I hope you don't mind - I took the liberty to rebase against master branch and force push. I'm running the behavior tests locally and plan to press the merge button if they pass. Actually I think I'll wait for the CI since it has been rebased against many commits.