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

Mehdi Amini llvmlistbot at llvm.org
Tue Nov 21 23:37:39 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) {}
----------------
joker-eph wrote:

> As far as ADT is concerned, I don't think this is NFC. It changes the functionality of the ADT, by allowing new usage that wasn't allowed before. 

I disagree with your characterization of NFC: it does not add any observable behavior of a correctly running program. This is consistent with a lot of NFC compiler change.

> I think this would be the equivalent of a command line tool that takes ELF files, say, then is generalized to take any object files -using some existing API that handles all object files - we'd still add a lit test that shows the new functionality

We're talking about a container: there is nothing I can do at runtime here that I couldn't do before. This is basically removing a cast at the call-site, it "pleases" the C++ type system: nothing else. And the C++ type system does not persist beyond the parser, so again: no program runtime behavior.
Your example is in a totally different category here.






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


More information about the Mlir-commits mailing list