This is an archive of the discontinued LLVM Phabricator instance.

Use std::foo_t rather than std::foo in LLVM.
ClosedPublic

Authored by jlebar on Feb 10 2020, 10:22 PM.

Details

Summary

C++14 migration. No functional change.

Diff Detail

Event Timeline

jlebar created this revision.Feb 10 2020, 10:22 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald Transcript
jlebar updated this revision to Diff 243740.Feb 10 2020, 10:33 PM

Rebase to origin/master.

MaskRay accepted this revision.Feb 10 2020, 10:42 PM
MaskRay added a subscriber: MaskRay.

Such changes can be risky. Hope someone can verify the build on Windows.

This revision is now accepted and ready to land.Feb 10 2020, 10:42 PM

You may join https://reviews.llvm.org/project/view/78/ and let the bot test Linux for you..

Such changes can be risky.

Heh, well said. I feel good about it because I found two or three real bugs in clang/llvm as a result of this cleanup. But still, we've got to land it safely...

I joined the group; what do I do to get tests run for this?

Hope someone can verify the build on Windows.

Do you think I should go on IRC and ask?

bkramer accepted this revision.Feb 11 2020, 2:27 AM

<courage wolf>Push and watch the bots</courage wolf>

This revision was automatically updated to reflect the committed changes.
thakis added a subscriber: thakis.Feb 12 2020, 7:10 AM

Looks like this broke building on windows with clang-cl as host compiler in some situations: http://45.33.8.238/win/8160/step_4.txt

I'm not sure if that's a bug in the version of the host clang I'm using yet. I'll poke around a bit and let you know.

jlebar added a comment.EditedFeb 12 2020, 8:09 AM

Looks like this broke building on windows with clang-cl as host compiler in some situations: http://45.33.8.238/win/8160/step_4.txt

I'm testing out the following fix, which we verified works for Nico.

No idea why this only affects clang-cl. SFINAE is hard.

commit 10cf8de244df1402c2b87205f427440fb4c0d7b9
Author: Justin Lebar <jlebar@google.com>
Date:   Wed Feb 12 08:05:00 2020 -0800

    Fix compilation of Any.h header.
    
    In a previous patch I changed `std::decay<T>::type` to `std::decay<T>`
    rather than `std::decay_t<T>`.  This seems to have broken the build
    *only for clang-cl*.  I don't know why.

diff --git a/llvm/include/llvm/ADT/Any.h b/llvm/include/llvm/ADT/Any.h
index 9d819841e3f..0aded628cda 100644
--- a/llvm/include/llvm/ADT/Any.h
+++ b/llvm/include/llvm/ADT/Any.h
@@ -74,7 +74,7 @@ public:
                     // adopting it to work-around usage of `Any` with types that
                     // need to be implicitly convertible from an `Any`.
                     llvm::negation<std::is_convertible<Any, std::decay_t<T>>>,
-                    std::is_copy_constructible<std::decay<T>>>::value,
+                    std::is_copy_constructible<std::decay_t<T>>>::value,
                 int> = 0>
   Any(T &&Value) {
     Storage =

The ::value on this line is also busted, I'm pretty sure. I think the result is this SFINAE is always false, meaning the forwarding constructor just doesn't exist!

That landed in 17b77418121139c4e8cfb050d82ead3f29db7132. Sounds like there's more SFINAE to be fixed here, but my build is happy again. Thanks!