[LLVMdev] Addressing const reference in ArrayRef

[Duncan P. N. Exon Smith]

> On 2014-Aug-22, at 11:37, David Blaikie <dblaikie at gmail.com> wrote:
> 
> On Fri, Aug 22, 2014 at 11:22 AM, Duncan P. N. Exon Smith
> <dexonsmith at apple.com> wrote:
>> 
>>> On 2014-Aug-22, at 10:43, David Blaikie <dblaikie at gmail.com> wrote:
>>> 
>>> Yep - the convenience of one-element->ArrayRef is "cute" at best, I
>>> think. Having to wrap it doesn't seem detrimental. Would have to look
>>> at some numbers, though (if we could easily gather the number of
>>> instances of this - I'm not sure of the easiest way to do that, given
>>> the build system likes to stop after it sees an error).
>> 
>> diff --git a/include/llvm/ADT/ArrayRef.h b/include/llvm/ADT/ArrayRef.h
>> index 0351cf5..79f14da 100644
>> --- a/include/llvm/ADT/ArrayRef.h
>> +++ b/include/llvm/ADT/ArrayRef.h
>> @@ -68,7 +68,7 @@ namespace llvm {
>>     /*implicit*/ ArrayRef(NoneType) : Data(nullptr), Length(0) {}
>> 
>>     /// Construct an ArrayRef from a single element.
>> -    /*implicit*/ ArrayRef(const T &OneElt)
>> +    __attribute__((deprecated)) /*implicit*/ ArrayRef(const T &OneElt)
>>       : Data(&OneElt), Length(1) {}
>> 
>>     /// Construct an ArrayRef from a pointer and length.
>> 
>> and rebuilding LLVM and Clang gives me:
>> 
>> $ ninja 2>&1 | grep -e Wdeprecated-declarations | wc -l
>>    6083
> 
> Uniqued? I imagine a few are in headers.

Good point.

$ grep Wdeprecated-declarations warnings.log | sort -u | wc -l
     644