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

[via llvm-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:

> For the use cases in this PR we could do triple.normalize(CanonicalForm::FOUR_IDENT)
@clayborg / @jasonmolenda: Do you see a downside of what @dmpots suggested?    @dmpots had a good point in offline discussion that these are for display in LLDB, so it maybe preferred that they are normalized.  I agree with that, but I'm just not sure if that will change thing that you guys end up not like (similar to how I initially made the objfmt component to show up in the triple string).

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