[Support] Don't use StringRef::equals in Path.inc

[rorth]

The removal of StringRef::equals in
3fa409f broke the Solaris/sparcv9 and Solaris/amd64 buildbots:

In file included from /vol/llvm/src/llvm-project/git/llvm/lib/Support/Path.cpp:1200:
/vol/llvm/src/llvm-project/git/llvm/lib/Support/Unix/Path.inc:519:18: error: no member named 'equals' in 'llvm::StringRef'
  519 |   return !fstype.equals("nfs");
      |           ~~~~~~ ^

Fixed by switching to operator!= instead.

Tested on sparcv9-sun-solaris2.11 and amd64-pc-solaris2.11.

[llvmbot]

@llvm/pr-subscribers-llvm-support

Author: Rainer Orth (rorth)

Changes

The removal of StringRef::equals in
3fa409f broke the Solaris/sparcv9 and Solaris/amd64 buildbots:

In file included from /vol/llvm/src/llvm-project/git/llvm/lib/Support/Path.cpp:1200:
/vol/llvm/src/llvm-project/git/llvm/lib/Support/Unix/Path.inc:519:18: error: no member named 'equals' in 'llvm::StringRef'
  519 |   return !fstype.equals("nfs");
      |           ~~~~~~ ^

Fixed by switching to operator!= instead.

Tested on sparcv9-sun-solaris2.11 and amd64-pc-solaris2.11.

---

Full diff: https://github.com/llvm/llvm-project/pull/98839.diff

1 Files Affected:

• (modified) llvm/lib/Support/Unix/Path.inc (+1-1)

diff --git a/llvm/lib/Support/Unix/Path.inc b/llvm/lib/Support/Unix/Path.inc
index 6e679f74869f0..cf05db546e021 100644
--- a/llvm/lib/Support/Unix/Path.inc
+++ b/llvm/lib/Support/Unix/Path.inc
@@ -516,7 +516,7 @@ static bool is_local_impl(struct STATVFS &Vfs) {
   // target
   StringRef fstype(Vfs.f_basetype);
   // NFS is the only non-local fstype??
-  return !fstype.equals("nfs");
+  return fstype != "nfs";
 #elif defined(_AIX)
   // Call mntctl; try more than twice in case of timing issues with a concurrent
   // mount.

[rorth]

Committed to unbreak the builds.

[kazutakahirata]

Thanks!

[dwblaikie]

(for future reference - a simple build fix like this is probably fine to commit without precommit review/without a pull request - but generally if you make a pull request you should wait until it's reviewed (creating a pull request amounts to saying "I'm not confident in this change and want a second set of eyes before I commit it" - so then committing it without that review seems problematic). If you only wanted to create the pull request to run automated presubmit checks, please create the PR with the skip-precommit-approval to indicate that)

[rorth]

Thanks for the clarification. In the old days, before LLVM switched to pull requests, I'd just have committed the patch, especially in a case like this with an obvious patch to unbreak the build. However, I wasn't sure if this was appropriate in the new world, so meant to err on the side of caution while still restoring the build quickly.

Besides, I meant to alert Kazu, wondering if he'd missed the buildbot failure notification in [ADT] Remove StringRef::equals which wouldn't work with a simple commit.

Another advantage of the pull request route is that you get a verification of the description's markup.

If you only wanted to create the pull request to run automated presubmit checks, please create the PR with the skip-precommit-approval to indicate that)

That would be git commit --no-verify?

[dwblaikie]

Thanks for the clarification. In the old days, before LLVM switched to pull requests, I'd just have committed the patch, especially in a case like this with an obvious patch to unbreak the build. However, I wasn't sure if this was appropriate in the new world, so meant to err on the side of caution while still restoring the build quickly.

Yep yep, just mentioning that it is the same norms for now, pre or post switch to github PRs. Maybe one day we'll move to PRs only, but even then, hopefully something like a build fix will be relatively low-cost, maybe not require human review, etc.

Besides, I meant to alert Kazu, wondering if he'd missed the buildbot failure notification in [ADT] Remove StringRef::equals which wouldn't work with a simple commit.

Another advantage of the pull request route is that you get a verification of the description's markup.

If you only wanted to create the pull request to run automated presubmit checks, please create the PR with the skip-precommit-approval to indicate that)

That would be git commit --no-verify?

I don't think it's wired up to anything like that - something you can manually select in the web UI, maybe there's a way to add labels from the command line, but I'm not sure how.