RFC: Fix unchecked accesses to Expected<T>

[MatthiasJReisinger]

Hi everyone,

when trying to build Julia together with LLVM 3.9, I noticed that the build fails with the following error message:

Expected<T> must be checked before access or destruction.
Expected<T> value was in success state. (Note: Expected<T> values in success mode must still be checked prior to being destroyed).
Aborted (core dumped)

My Make.user looks as follows:

USE_SYSTEM_LLVM:=1
LLVM_CONFIG:=$(MY_LLVM_BUILD)/bin/llvm-config

MY_LLVM_BUILD points to a manually built LLVM installation of version 3.9, retrieved from LLVM's git mirror and compiled via cmake && make (i.e. no options have been passed to the build). The error can also be reproduced with the following Make.user:

LLVM_VER:=svn
LLVM_ASSERTIONS:=1
LLVM_DEBUG:=1

There are a number of places in debuginfo.cpp and jitlayers.cpp where Expected<T> values are accessed without checking beforehand if they contain an Error. This results in the above error message and execution gets aborted.

The given pull request fixes these usages of Expected<T> such that the build process with LLVM 3.9 is working again.

Furthermore, after having fixed the build, it turned out that, when running make testall, a few tests also fail due to unchecked accesses to Expected<T> values. However, I've not yet been able to identify the particular test cases that fail, since the error messages do not appear consistently after the same test cases when running the tests repeatedly. Are the tests maybe running asynchronously such that their output does not necessarily appear in order?

Since this is my first pull request here, I apologize in case I overlooked anything important.

Any comments are appreciated, thank you!

[vtjnash]

lgtm. you can run the test with JULIA_CPU_CORES=1 make test or equivalently make testall1 to get them to run linearly. otherwise it can be a bit of a guessing game to figure out which of the tests running in parallel caused the error. Otherwise, sometimes you can cross-reference between which test work died unexpectedly and figure out which test it was.

[MatthiasJReisinger]

Thank you! I've updated the PR, the tests are passing now.

[yuyichao]

Is the issue that bool(sNameOrError) has to be called? It seems that this won't work for release build where assertion is disabled by default.

[MatthiasJReisinger]

Yes, the issue is that Expected<T>::operator bool() has to be called before invoking Expected<T>::get(), but only if LLVM was built with assertions enabled. So this would cause a problem only if you want to build Julia with assertions disabled together with LLVM where assertions are enabled, which I did not consider. But how can a release build of Julia be triggered? Because when I simply invoke the build process via make without any manual configuration, then Julia will still be built with assertions enabled. However, I think a release build of Julia would normally use a release build of LLVM anyway? Because then this should not cause any problems.

[yuyichao]

I think assertion is disabled by default unless it is enabled by your CFLAGS.

[MatthiasJReisinger]

In src/Makefile the build rule for .c files uses the variable DISABLE_ASSERTIONS to pass
-DNDEBUG to the compiler by default, so indeed assertions will be enabled by default for .c files:

$(BUILDDIR)/%.o: $(SRCDIR)/%.c $(HEADERS) | $(BUILDDIR)
    @$(call PRINT_CC, $(CC) $(CPPFLAGS) $(CFLAGS) $(SHIPFLAGS) $(DISABLE_ASSERTIONS) -c $< -o $@)

However, the build rule for .cpp files does not use DISABLE_ASSERTIONS:

$(BUILDDIR)/%.o: $(SRCDIR)/%.cpp $(SRCDIR)/llvm-version.h $(HEADERS) $(LLVM_CONFIG_ABSOLUTE) | $(BUILDDIR)
    @$(call PRINT_CC, $(CXX) $(shell $(LLVM_CONFIG_HOST) --cxxflags) $(CPPFLAGS) $(CXXFLAGS) $(SHIPFLAGS) -c $< -o $@)

Hence, it seems that assertions will always be enabled when compiling the src/*.cpp files (unless -DNDEBUG will be passed manually). I'm wondering if this is intended?

[vtjnash]

yes, for the CXX files, we inherit the NDEBUG flag from llvm-config

[MatthiasJReisinger]

You are right, thank you, I overlooked that. So there won't be issues with the release build.