In D131858#3984855, @arphaman wrote:

Ping @mizvekov.

Unfortunately I'm unable to revert this commit now so we won't be able to get the bot back to green until it's fixed.

@alexfh Thanks!

In D136565#3911884, @alexfh wrote:

Hi Matheus, 279fe6281d2ca5b2318c7437316c28750feaac8d causes compilation timeout on some of our internal files.

FYI just another data point, I haven't taken a closer look yet, but now we start diagnosing some deprecated uses of std::experimental::pmr::polymorphic_allocator on current libc++ linux CI.

In D127695#3860316, @rjmccall wrote:

I see, thank you. I know you've marked this a WIP, but it's always good to describe these things in the patch description; that's what it's for.

In D136533#3899628, @ldionne wrote:

It might be a problem, but I would argue we should still do it after fixing any problematic cases. It seems like Clang's current behavior is broken, as it basically ignores the [[deprecated]] attribute on aliases?

I'll need to have another look at this, apparently the synthesized std namespace breaks some tests on arm platforms.

In D136533#3896313, @ldionne wrote:

Looking at that commit, which had nothing to do with fixing availability markup, I think this Clang patch might still be missing some diagnostics? Should it diagnose when the typename is accessed through an alias?

If that's the case, libc++ would fail with trunk as well, since 5fab33af7f083 would not silence these issues. And if that's the case, then I am not sure how to fix libc++ at all. I suspect the problem here is really https://github.com/llvm/llvm-project/issues/40340, since we do mark the filesystem classes as unavailable as we should.

It's not clear to me there is anything wrong besides our not importing of va_list_tag.
The imported TypedefType should have the same underlying type as the original one, and I did not find anything different is happening on that test case.

@rtrieu @hokein I just proposed a fix for this at https://reviews.llvm.org/D136977

I agree having two different val_list types is suspect, it might not have been imported and is simply referring to the va_list of the original context.

In D136533#3891905, @ldionne wrote:

Is it possible that it would be one of those two bugs? https://github.com/llvm/llvm-project/issues?q=is%3Aopen+is%3Aissue+author%3Aldionne+availability+

Thanks for confirming.

I think there is a high chance that the bug that caused richard's patch to be reverted, was actually fixed afterwards by https://github.com/llvm/llvm-project/commit/acb767f5cda59302aa9100afcf6133d66779d42c

This is surprisingly not from a bug in this patch.

In D136533#3886666, @glandium wrote:

It's the opposite of deprecated, it's (optionally) using something that is only available in newer versions of macos.

Reduced to:

void foo();
template <void () = foo> void bar() {}
template void bar<>();
template void bar<foo>();

In D134453#3885423, @aaron.ballman wrote:

I can live with this approach if folks think it's the better way to go. But my concern still remains that the user has no idea what's being constructed by {3} or {4} without tracking down which constructor of t1 is being called. Because of overloads, std::initializer_list, and conversion operators (and the fact that C++ initialization rules are a bit of a disaster), I think this can be unobvious sometimes without including type names. That said, after playing around a bit, I think those times might involve more contorted code than others are worried about, and so maybe it's not worth worrying about those cases. The fact that Clang is the only C++ compiler that doesn't print full type information makes me wary though. My thinking is that it's always more frustrating to have not enough information in a diagnostic than too much information (both are problems in their own ways though).

In D136533#3884364, @glandium wrote:

(And specifically, FuzzerFork.cpp doesn't use any of those declared things. Its only sin is to #include <fstream>, which happens to have /some/ methods (std::filesystem-related) only available on macos 10.15+.)

Edit: Corollary: anything that #include <fstream>, builds with C++17 or more, and wants to support macos < 10.15, is broken by this patch.

In D133874#3884904, @glandium wrote:

I'm running it through creduce (as well as the one for D136564. It's going to take a little while. Thank you for the revert.