[clang] [lldb] [llvm] [lldb] Fix object format in the Triple of Mach-O files (approach 4) (PR #145157)

[via cfe-commits]

================
@@ -463,6 +463,27 @@ class Triple {
 
   const std::string &str() const { return Data; }
 
+  /// Return the triple string but only keep the first \p N components.
+  ///
+  /// The returned string will preserve the first \p N components exactly the
+  /// same as the original (including the leading "-" and the value, empty or
+  /// not).
+  ///
+  /// E.g. Triple("arm64-apple-ios").str(5) == "arm64-apple-ios"
+  /// E.g. Triple("arm64-apple-ios--").str(5) == "arm64-apple-ios--"
+  /// E.g. Triple("arm64-apple-ios--").str(4) == "arm64-apple-ios-"
+  /// E.g. Triple("arm64-apple-ios--").str(3) == "arm64-apple-ios"
+  /// E.g. Triple("arm64-apple-ios--").str(2) == "arm64-apple"
+  /// E.g. Triple("arm64-apple-ios--").str(1) == "arm64"
+  /// E.g. Triple("arm64-apple-ios--").str(0) == ""
+  ///
+  /// This method does not normalize any triple strings. Clients that need to
+  /// handle the non-canonical triples that users often specify should use the
+  /// normalize method.
+  ///
+  /// \returns the (shorterned) triple string.
+  StringRef str(size_t N) const;
----------------
royitaqi wrote:

The difference between this new method `str(N)` and `normalize()` is that the former won't canonicalize the triple string and the latter will.

>From method doc of `normalize()`:
> In particular, it handles the common case in which otherwise valid components are in the wrong order.

So I think `str(N)` can be seen as an alternative to `normalize()` where the triple string isn't canonicalized.

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