LLVM Discussion Forums

What do 'abi breaking checks' do?

Hello! I’m a new developer on an existing project that uses LLVM 6.0.1.

When running tests on Linux (though not on Windows), I am getting the following exception:

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

Stepping through the code, I see that it’s checking whether the ‘Unchecked’ member variable is ‘true’ (which it is).

This code ran as a result of calling this, from our own code:

std::unique_ptrllvm::object::ObjectFile objectFile(std::move(objectFileExpected.get()));

(it’s the call to ‘get’ that triggers the error.)

If I’m reading things correctly, the system wants me to ‘check’ the objectFileExpected, before it’s allowed to validly return a value from ‘get’.

This is where my understanding breaks down. What is ‘checking’ in this context, and what do I need to do to check the object in question? What would I do if checking it reported there was a problem?

Thank you!

The title of this seems a bit confusing to me, “abi breaking check” is an unrelated concept here.

What you’re hitting is summarized by “Expected must be checked before access or destruction”: basically an “Expected” is documented as a “Tagged union holding either a T or a Error”. Since when you get an expected you don’t know if you have a T or an Error, you are supposed to check the state of the Expected (using the bool operator).

To answer “What would I do if checking it reported there was a problem”, well it depends on the context in which you’re using: you may propagate an error above for example.

Sorry about the title; I originally had the “LLVM_ENABLE_ABI_BREAKING_CHECKS” in there, because that’s wrapped around the bit that’s throwing, but the forum software didn’t think it was a sentence or something.

Thank you! That makes more sense, and I was able to fix the issue.

For posterity: before calling:

objectFileExpected.get()

I added:

if (!objectFileExpected) {
auto err = objectFileExpected.takeError();
//Then deal with error
}

Haven’t actually tested the part inside, since I haven’t found a situation that gives me an error for that Expected. But that’s my reading of what it should look like from the code.