Don't use std::errc

[ABataev]

Summary

As noted on Errc.h:

* std::errc is just marked with is_error_condition_enum. This means that
common patters like AnErrorCode == errc::no_such_file_or_directory take
// 4 virtual calls instead of two comparisons.

And on some libstdc++ those virtual functions conclude that

---

int main() {

std::error_code foo = std::make_error_code(std::errc::no_such_file_or_directory);
return foo == std::errc::no_such_file_or_directory;

}

should exit with 0.

[thakis]

This isn't in a hot codepath, so the virtual calls aren't super important.

This not working in some libstdc++s is important of course, but llvm's Errc.h claims "std::error_code works OK on all platforms we use". I guess that's not true? Can you include more details on which platforms this is broken?

[ABataev]

In D66143#1627157, @thakis wrote:

This isn't in a hot codepath, so the virtual calls aren't super important.

This not working in some libstdc++s is important of course, but llvm's Errc.h claims "std::error_code works OK on all platforms we use". I guess that's not true? Can you include more details on which platforms this is broken?

PowerPC, Ubuntu 14.04.3 LTS, for example.

[ABataev]

std::error_code works correctly, it is std::make_error_code leads to something strange in some cases.

[thakis]

That's Trusty and Trusty is on 4.8 which we no longer support, right?

[ABataev]

In D66143#1627165, @thakis wrote:

That's Trusty and Trusty is on 4.8 which we no longer support, right?

It is still supported with some extra cmake flags.

[xbolva00]

GCC 4.8 is still supported

[xbolva00]

This small change is okay anyway

[ABataev]

Also, there is a clang unit test that fails because of the same reason. Can I include the changes in this test into this patch too or better to make a separate patch? The test is unittests/Basic/FileManagerTest.cpp

[thakis]

As far as I know 4.8 is no longer supported.

In D66143#1627168, @ABataev wrote:

In D66143#1627165, @thakis wrote:

That's Trusty and Trusty is on 4.8 which we no longer support, right?

It is still supported with some extra cmake flags.

It used to be, but that's no longer true. r366333 added an unconditional use of <regex> which doesn't exist in 4.8.

[ABataev]

In D66143#1627195, @thakis wrote:

As far as I know 4.8 is no longer supported.

In D66143#1627168, @ABataev wrote:

In D66143#1627165, @thakis wrote:

That's Trusty and Trusty is on 4.8 which we no longer support, right?

It is still supported with some extra cmake flags.

It used to be, but that's no longer true. r366333 added an unconditional use of <regex> which doesn't exist in 4.8.

This is only for lld. Plus, there was no final decision to drop support for 4.8 and all other LLVM subprojects still can be compiled with 4.8 without any problems.

[lebedev.ri]

In D66143#1627221, @ABataev wrote:

In D66143#1627195, @thakis wrote:

As far as I know 4.8 is no longer supported.

In D66143#1627168, @ABataev wrote:

In D66143#1627165, @thakis wrote:

That's Trusty and Trusty is on 4.8 which we no longer support, right?

It is still supported with some extra cmake flags.

It used to be, but that's no longer true. r366333 added an unconditional use of <regex> which doesn't exist in 4.8.

This is only for lld. Plus, there was no final decision to drop support for 4.8

I'm not sure this is correct

and all other LLVM subprojects still can be compiled with 4.8 without any problems.

Not for long. https://lists.llvm.org/pipermail/llvm-dev/2019-August/134360.html

[jfb]

In D66143#1627226, @lebedev.ri wrote:

In D66143#1627221, @ABataev wrote:

In D66143#1627195, @thakis wrote:

As far as I know 4.8 is no longer supported.

In D66143#1627168, @ABataev wrote:

In D66143#1627165, @thakis wrote:

That's Trusty and Trusty is on 4.8 which we no longer support, right?

It is still supported with some extra cmake flags.

It used to be, but that's no longer true. r366333 added an unconditional use of <regex> which doesn't exist in 4.8.

This is only for lld. Plus, there was no final decision to drop support for 4.8

I'm not sure this is correct

and all other LLVM subprojects still can be compiled with 4.8 without any problems.

Not for long. https://lists.llvm.org/pipermail/llvm-dev/2019-August/134360.html

4.8 is still supported, but I intend to move the minimum version forward as soon as I find time now that there's no blocker.

[thakis]

Should we revert the change in lld then? LLVM has a global policy for this; if 4.8 is still supported then regex can't be used yet.

Please mention in the commit message that this is a workaround for gcc 4.8; with that lgtm (for another 2 weeks or so ;) ).

[thakis]

FWIW it looks like 4.8 support is going away in days, not weeks, see D66188.

cfe/trunk/lib/Lex/HeaderSearch.cpp

 #include "clang/Lex/Preprocessor.h"
 #include "llvm/ADT/APInt.h"
 #include "llvm/ADT/Hashing.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Allocator.h"
 #include "llvm/Support/Capacity.h"
+#include "llvm/Support/Errc.h"
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/VirtualFileSystem.h"
 #include <algorithm>
 #include <cassert>
 #include <cstddef>
 #include <cstdio>
const FileEntry *HeaderSearch::getFileAndSuggestModule(
   // If we have a module map that might map this header, load it and
   // check whether we'll have a suggestion for a module.
   llvm::ErrorOr<const FileEntry *> File =
       getFileMgr().getFile(FileName, /*OpenFile=*/true);
   if (!File) {
     // For rare, surprising errors (e.g. "out of file handles"), diag the EC
     // message.
     std::error_code EC = File.getError();
-    if (EC != std::errc::no_such_file_or_directory &&
-        EC != std::errc::invalid_argument && EC != std::errc::is_a_directory &&
-        EC != std::errc::not_a_directory) {
+    if (EC != llvm::errc::no_such_file_or_directory &&
+        EC != llvm::errc::invalid_argument &&
+        EC != llvm::errc::is_a_directory && EC != llvm::errc::not_a_directory) {
       Diags.Report(IncludeLoc, diag::err_cannot_open_file)
           << FileName << EC.message();
     }
     return nullptr;
   }
 
   // If there is a module that corresponds to this header, suggest it.
   if (!findUsableModuleForHeader(*File, Dir ? Dir : (*File)->getDir(),