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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
