[PATCH] D86892: Improve error handling for SmallVector programming errors.

[Geoffrey Martin-Noble via Phabricator via llvm-commits]

GMNGeoffrey added a comment.

In D86892#2248297 <https://reviews.llvm.org/D86892#2248297>, @mehdi_amini wrote:

> In D86892#2248235 <https://reviews.llvm.org/D86892#2248235>, @GMNGeoffrey wrote:
>
>> In D86892#2248125 <https://reviews.llvm.org/D86892#2248125>, @mehdi_amini wrote:
>>
>>>> I disagree. report_bad_alloc_error reports an OOM, which this is not. There is no amount of system memory that would make this not an error.
>>>
>>> What would `new` do?
>>
>> What's the question exactly?
>
> Would `new char[std::numeric_limit<uint64_t>::max()];` issue an OOM exception? (The `There is no amount of system memory that would make this not an error` applies equally well here).

array is too large (18446744073709551615 elements)

  new char[std::numeric_limits<uint64_t>::max()];

> I guess a more accurate comparison would be what would `std::vector<int> vec; vec.resize(-1);` do?  (throw `std::length_error` is the answer)

std::__u::__throw_length_error(char const*)

My point here is that we can provide a better and more specific error message, so reporting an OOM is pretty unhelpful. An assert would be another option, although if we're already reporting some sort of fatal error here even not in debug mode it seems redundant.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86892/new/

https://reviews.llvm.org/D86892