This is an archive of the discontinued LLVM Phabricator instance.

Introduce `__sanitizer::ArrayRef<T>` type.
AbandonedPublic

Authored by delcypher on Apr 13 2020, 1:21 PM.

Details

Summary

This type is a light-weight container around a contiguous sequence
of elements of type T.

The type is inspired by LLVM ADT's ArrayRef but has more limited
functionality.

This patch includes tests for the new type but no uses in the runtime
itself. In future patches I will use this type as a foundation for
building a safe abstraction for operating on an environment array.

Diff Detail

Event Timeline

delcypher created this revision.Apr 13 2020, 1:21 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 13 2020, 1:21 PM
Herald added subscribers: Restricted Project, jfb, mgorny. · View Herald Transcript

While I'm in favor of this type looking more like llvm's MutableArrayRef (ie: allowing mutability or immutability to be encoded in the type parameter (const T versus non-const T)) rather than needing the two types LLVM has (ArrayRef + MutableArrayRef). I wonder if having this type called "ArrayRef" when it is subtly different from llvm's ArrayRef might be confusing? Wonder if it needs another/better name - though the standard doesn't offer us a great alternative, it seems the standardized equivalent is std::span, which might be sufficiently different not to be a good name to use either? Not sure.

compiler-rt/lib/sanitizer_common/sanitizer_array_ref.h
87 ↗(On Diff #257090)

Might just be better/easier to use "data_" directly, rather than const_casting+begin?

Or use "data()" instead, like llvm::ArrayRef does?

delcypher marked an inline comment as done.Apr 13 2020, 9:42 PM

While I'm in favor of this type looking more like llvm's MutableArrayRef (ie: allowing mutability or immutability to be encoded in the type parameter (const T versus non-const T)) rather than needing the two types LLVM has (ArrayRef + MutableArrayRef). I wonder if having this type called "ArrayRef" when it is subtly different from llvm's ArrayRef might be confusing?

Thank you for raising this. I probably should have said "loosely inspired" by ArrayRef because I wasn't aware of MutableArrayRef and I hadn't noticed that LLVM ADT's ArrayRef was immutable. Given that LLVM's ADT ArrayRef is immutable my choice of naming would certainly be confusing. For my use case I actually only need the underlying data to be mutable so I don't need an immutable version.

Wonder if it needs another/better name - though the standard doesn't offer us a great alternative, it seems the standardized equivalent is std::span, which might be sufficiently different not to be a good name to use either? Not sure.

My early draft name was actually BufferRef<T>. Does that seem any better?

compiler-rt/lib/sanitizer_common/sanitizer_array_ref.h
87 ↗(On Diff #257090)

Good idea.

While I'm in favor of this type looking more like llvm's MutableArrayRef (ie: allowing mutability or immutability to be encoded in the type parameter (const T versus non-const T)) rather than needing the two types LLVM has (ArrayRef + MutableArrayRef). I wonder if having this type called "ArrayRef" when it is subtly different from llvm's ArrayRef might be confusing?

Thank you for raising this. I probably should have said "loosely inspired" by ArrayRef because I wasn't aware of MutableArrayRef and I hadn't noticed that LLVM ADT's ArrayRef was immutable. Given that LLVM's ADT ArrayRef is immutable my choice of naming would certainly be confusing. For my use case I actually only need the underlying data to be mutable so I don't need an immutable version.

Wonder if it needs another/better name - though the standard doesn't offer us a great alternative, it seems the standardized equivalent is std::span, which might be sufficiently different not to be a good name to use either? Not sure.

My early draft name was actually BufferRef<T>. Does that seem any better?

Might be best just to resort to calling it MutableArrayRef to match LLVM's since they're so similar? Maybe one day we can revisit the design decision in LLVM and fix both, etc.

  • Rename ArrayRef<T> -> MutableArrayRef<T>.
  • Remove duplicate const returning methods. They don't seem to be needed.
  • Add elementTy.
  • Add iterator type.

Don't suppose there's any sane way to reuse any part of the main llvm version? Might at least be worth a few comments encouraging future developers to try to keep this mostly aligned with the llvm one? (maybe document broadly the features/etc that are omitted from this version but present in the llvm one)

Is this more or less copy/paste, except for some features that aren't supportable/suitable for this usage?

compiler-rt/lib/sanitizer_common/sanitizer_mutable_array_ref.h
82

Going to use data() here?

delcypher updated this revision to Diff 257566.Apr 14 2020, 5:16 PM
delcypher marked an inline comment as done.

Remove unnecessary const_cast<>.

Don't suppose there's any sane way to reuse any part of the main llvm version? Might at least be worth a few comments encouraging future developers to try to keep this mostly aligned with the llvm one? (maybe document broadly the features/etc that are omitted from this version but present in the llvm one)

We can't depend on libcxx in the compiler-rt runtimes. There's probably something crazy we could with macros that fudge the types to make it work but that doesn't sound sane.

Is this more or less copy/paste, except for some features that aren't supportable/suitable for this usage?

Not really. It just has the bare minimum functionality that I needed. I only looked at ArrayRef<> when I needed to do something I didn't know how to implement.

compiler-rt/lib/sanitizer_common/sanitizer_mutable_array_ref.h
82

Oh sorry. I missed this. I'll fix this.