This is an archive of the discontinued LLVM Phabricator instance.

Use VersionTuple for parsing versions in Triple
ClosedPublic

Authored by jamesfarrell on Dec 7 2021, 8:18 AM.

Details

Summary

Reapply "Use VersionTuple for parsing versions in Triple" (v3)

Changed in v3 (This commit): Call rtrim() on the output of the commands in the unit tests, since the new
version parsing code fails if there are leftover characters like \n.

v2 reverted in 63a6348cad6caccf285c1661bc60d8ba5a40c972

Changed in v2 (50324670342d9391f62671685f4d6b4880a4ea9a): Remove some #if defined() conditional compilation for Apple and AIX in the Host unit tests and make sure the code at least compiles.

Original commit reverted in 40d5eeac6cd89a2360c3ba997cbaa816abca828c

Original commit message (1e8286467036d8ef1a972de723f805a4981b2692):

Use VersionTuple for parsing versions in Triple. This makes it possible to distinguish between "16" and "16.0" after parsing, which previously was not possible.

Diff Detail

Event Timeline

jamesfarrell created this revision.Dec 7 2021, 8:18 AM
jamesfarrell requested review of this revision.Dec 7 2021, 8:18 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptDec 7 2021, 8:18 AM

Only change from previous attempt is to call rtrim() on the output of the commands in the unit tests, since the new version parsing code fails if there are leftover characters like \n.

Only change from previous attempt is to call rtrim() on the output of the commands in the unit tests, since the new version parsing code fails if there are leftover characters like \n.

My only comment is on the commit message, which ideally would be a bit easier to get information from:

  • the summary line is very very long; can you cut it down, and put more in the body?
  • it'd be great to link directly to the commit that's being reapplied as well (both the most recent and the original)

E.g., something like this, but feel free to reword / add more info / etc:

Reapply "Use VersionTuple for parsing versions in Triple" (v3)

Revert SHA1-1, reapplying SHA1-2 after fixing unit tests. The only change is
to call rtrim() on the output of the commands in the unit tests, since the new
version parsing code fails if there are leftover characters like `\n`.

The original commit message (from SHA1-3) follows:

Use VersionTuple for parsing versions in Triple. This makes it possible to distinguish between "16" and "16.0" after parsing, which previously was not possible.
jamesfarrell retitled this revision from Revert "Revert "Use VersionTuple for parsing versions in Triple, fixing issues that caused the original change to be reverted. This makes it possible to distinguish between "16" and "16.0" after parsing, which previously was not possible."" to Use VersionTuple for parsing versions in Triple.Dec 7 2021, 12:36 PM
jamesfarrell edited the summary of this revision. (Show Details)
jamesfarrell edited the summary of this revision. (Show Details)Dec 7 2021, 2:19 PM
danalbert accepted this revision.Dec 7 2021, 2:31 PM
This revision is now accepted and ready to land.Dec 7 2021, 2:31 PM
This revision was landed with ongoing or failed builds.Dec 7 2021, 3:15 PM
This revision was automatically updated to reflect the committed changes.
MaskRay added a subscriber: MaskRay.EditedDec 7 2021, 3:28 PM

commit 219672b8dd06c4765185fa3161c98437d49b4a1b says Revert "Revert "...""

For such commits, it is customary to use "Reland " and the commit message should include the original message (people don't like chasing through several commits to obtain the important original message) and a short note about what was fixed, so that people doing archaeology can know better what's going on.

commit 219672b8dd06c4765185fa3161c98437d49b4a1b says Revert "Revert "...""

For such commits, it is customary to use "Reland " and the commit message should include the original message (people don't like chasing through several commits to obtain the important original message) and a short note about what was fixed, so that people doing archaeology can know better what's going on.

Ugh...I described it very carefully in the summary for https://reviews.llvm.org/D115254, but didn't realize that was not what got attached to the change when I merged it. Apologies.