[flang-commits] [flang] [mlir] Make MLIR Value more consistent in terms of `const` "correctness" (NFC) (PR #72765)

Fangrui Song via flang-commits flang-commits at lists.llvm.org
Wed Nov 22 14:42:59 PST 2023


================
@@ -335,8 +335,9 @@ namespace llvm {
     MutableArrayRef(T *begin, T *end) : ArrayRef<T>(begin, end) {}
 
     /// Construct a MutableArrayRef from a SmallVector.
-    /*implicit*/ MutableArrayRef(SmallVectorImpl<T> &Vec)
-    : ArrayRef<T>(Vec) {}
+    template <typename U>
+    /*implicit*/ MutableArrayRef(const SmallVectorTemplateCommon<T, U> &Vec)
+        : ArrayRef<T>(Vec) {}
----------------
MaskRay wrote:

I think "NFC" is ambiguous. It certainly should not change the behavior of all accepted input, but the term is ambiguous on whether (a) new symbols can be exported or (b) new uses are allowed.

The latest revision of the pull request does not touch `ArrayRef.h`.
For new functions in ADT, we definitely need a unittest.
For a change of function signature so that more uses are allowed, I think both practices exist.
I try to do this for my own changes for https://maskray.me/blog/2021-08-08-toolchain-testing#the-test-checks-at-the-wrong-layer

Note: the constructor signature change is related to an exported widely-used header and the ctor can be used in many clients.
If it is a change to a type that appears "internal", I'd not bother with a test.


https://github.com/llvm/llvm-project/pull/72765


More information about the flang-commits mailing list