[clang] Support target names with dots in more utilities (PR #65812)

via cfe-commits cfe-commits at lists.llvm.org
Mon Sep 18 09:12:21 PDT 2023


dankm wrote:

> Just making sure I follow: the problem with `stem` is that if a filename includes a dot, but no ".exe" or equivalent suffix, it would drop the bit from the last dot onwards, even though it might be part of the tool's actual name. Is that correct?

Yes, that's correct. The real examples I've run into have been `x86_64-unknown-freebsd13.2-clang`, fixed in [D135284](https://reviews.llvm.org/D135284), and the `llvm-ar` and `llvm-ranlib` cases in this PR. In both cases they had previously been using `stem` and returning `x86_64-unknown-freebsd13` and then failing to determine the tool name. I was mostly concerned with the cases where behaviour was affected. Tool name printing is valid too, though, of course.

> It looks like a number of tools have changed, but I don't see equivalent test changes/new tests for all of them. It seems like we should have testing for all cases where the code goes to some attempt to print the tool name. Assuming it is, I note that some tools no longer will drop "other" file extensions. However, I don't know of any real such extensions other than Window's ".exe". Do any others exist on other platforms?

This makes sense. For my first round I did leave out the cases where having multiple dots in the tool name didn't make sense, such as for `dlltool` or `llvm-rc`. You're right though that we should test those. I'll add more tests, and see if I can find more examples of using `stem` or `filename` when printing a tool name.

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


More information about the cfe-commits mailing list