This addresses the issue pointed out in D31890 regarding a potentially confusing api for using unique_ptr in conjunction with dyn_cast. It does so by implementing this not as a specialization / overload of dyn_cast, but as an entirely new function unique_dyn_cast. Adding unique to the name makes clear through the API that the function will conditionally destroy the input if the cast succeeds, and leave the input alone if the cast fails. A matching unique_dyn_cast_or_null is added as well.
Details
Diff Detail
Event Timeline
Can the pieces of the test case be grouped together (currently it's classes, then some other things, then traits, then some other things, then the tests that use them)?
Also - having bits of one part of the test feed into another otherwise independent part of the test seems a bit sub-optimal. (I realize you're using ASSERT_* so if the first fails tehre won't be spurious failures in the latter tests - but it means you only get the first result from the test and nothing else) - I'd suggest splitting it up to at least be independent, and possibly to be in separate test functions so they can report independent results, etc.
llvm/include/llvm/Support/Casting.h | ||
---|---|---|
363 | I'd probably phrase this as "From is null on exit". (nullptr is a specific null literal, the concept of nullness is independent of nullptr (or NULL, or 0, etc) and "refers to null" seems a bit awkward/inaccurate because it doesn't refer to anything) | |
llvm/unittests/Support/Casting.cpp | ||
47 | you can drop the "public" in "public base" here, since it's a struct and has default public visibility | |
52 | 'inline' isn't needed here | |
59 | 'inline' isn't needed here |
I'd probably phrase this as "From is null on exit". (nullptr is a specific null literal, the concept of nullness is independent of nullptr (or NULL, or 0, etc) and "refers to null" seems a bit awkward/inaccurate because it doesn't refer to anything)