Check that memory allocation succeeds before use.
Rename variable DescInfo to DI for consistency.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Isn't this just dead code? a non-nothrow new will never return null http://en.cppreference.com/w/cpp/memory/new/operator_new
We don't use exceptions in LLVM.
Can you elaborate on what the bigger picture is? LLVM is *not* robust against allocation failures, and fixing just this bit won't change anything.
As llvm is mostly an api, i assumed that it would be robust and this was a one-off.
Anything big should be done automagically, so i am going to look at sic-ing clang-tidy and/or the static analyzer at this problem.
The lack of exception handling i can understand for performance reasons but it does put normal use of the std library in a bind if like this case the default uses exceptions.
It would be nice if there was project wide design on how to handle exceptions/errors.
If there is please point me at it.
Before spending time on this, I'd suggest asking on llvm-dev@ about whether we _should_ make LLVM robust against allocation failures. I believe (but you should still ask) the consensus will be that it isn't worth the engineering complexity to make LLVM as a library robust against allocation failures, and that if you do want this, the right fix is to fork out to LLVM as a separate process.
The lack of exception handling i can understand for performance reasons but it does put normal use of the std library in a bind if like this case the default uses exceptions.
It would be nice if there was project wide design on how to handle exceptions/errors.
If there is please point me at it.
https://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions
I agree on the consensus building.
However I can see the problem of default new not returning nullptr being a general problem.
So something automagic needs to be created if it doesn't exist already.