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.