Hi Jim, this change broke my Fedora 33 Linux (x86) box. Do you think we can get a quick fix or revert this?

And just to be clear, the source directory in my setup is in the home directory. My cron job / "bot" build just builds in /tmp.

Line 18 fails: %lldb -x -b --replay %t.repro >> %t.txt 2>&1

error: reproducer replay failed:
warning: home directory '/home/dave' not in VFS

Hello. I have an auto-bisecting multi-stage bot that has identified this change as breaking release (without assertions) testing on Fedora 33 x86-64. Can we get a quick fix or revert this change for now?

In D86354#2240009, @dblaikie wrote:

In D86354#2240001, @varungandhi-apple wrote:

This seems to only allow empty optionals to be constexpr. Should the non-default constructor also be constexpr?

The reason I implemented the minimal thing was that I wasn't sure how far I should go. In a Swift PR, @davezarzycki raised the point about constexpr potentially leading to longer compile times even when not used for compile-time computation. I asked some folks internally at Apple and the response I got was along the lines of, "That's surprising... If that's actually the case, it should be reported as a Clang bug". I haven't been able to dedicate time to benchmarking the impact of constexpr on compile time... Since Optional is a currency type, I wasn't sure if people would object to more methods being marked constexpr. In principle, I don't see any reason for any method on Optional to not be constexpr.

That upstream thread doesn't look like it's talking about the impact of constexpr in non-constexpr contexts. Yes, making a variable constexpr when you don't need it to be can have negative compile time consequences - but in Clang I don't believe (again, can be bugs, but it doesn't sound like that swift thread is suggesting the existence of such bugs) a constexpr function called in a non-constexpr context is handled any differently than if it were a non-constexpr function. (GCC is different in this regard and does try to do constexpr things in non-constexpr contexts, though unclear how hard it tries before bailing out to the non-constexpr handling)

Not fighting with how lit, FileCheck, and shell input/output work would help here:

I have an auto-bisecting cron job that has identified the "reland" as breaking the test suite on Fedora 32 (x86). Is there a quick fix or can we revert the reland?

Why were static "get" methods preferred over simply marking the constructor explicit? For example, if the constructor is marked explicit, then this is what users see:

Hello, I have a twice-daily auto-bisecting multi-stage cron job running on Fedora 32 (x86-64) that has identified this commit as failing my first stage test (release + no asserts). Is this expected? Can we get a quick fix or revert this?

I have a multi-stage, auto-git-bisecting bot that has identifying this commit as the source of a regression on Fedora 32 (x86-64). This commit broke my first stage test (release, no asserts). Might a quick fix happen or do we need to revert this?

Hello. I have an auto-bisecting multi-stage bot that is failing on two after this change. Can we please revert this or commit a quick fix?

What compilers was this tested on? This seems to be failing on clang 10 (Fedora 32 x86-64). Can we revert this or commit a quick fix?

Now that my core concern is addressed (moving clang's default module cache out of /tmp), I don't have the time to push for this deprecation. Sorry.

Moved clang specific changes to: https://reviews.llvm.org/D82362

1. Respect Darwin and XDG cache directories.
2. Drop atypical reverse DNS in the path.
3. Make clang more robust if the default module path cannot be determined.

Sure, we can honor XDG_CACHE_DIR. Maybe as a followup, somebody can wire up Darwin's cache directory (which is retrievable via a BSD specific confstr() API with _CS_DARWIN_USER_CACHE_DIR). I'm not sure about other platforms.

Unless I'm missing something, consolidating this logic into LLVM's CMakeLists.txt will break stand alone builds of sub-projects and external projects that depend on this logic.

“N/300” implies that you’re not building all of llvm, clang, etc otherwise thousands of files would build.

Naive build output is one line per file (plus output).

This change breaks building on Fedora 32 with clang-10 (as shipped by Fedora). Can we revert this or commit a quick fix?

I'm going to abandon this change for now. The problem is that the MS extensions are not as pervasive through the language as I wanted. For example, I'd really like them to work on aggregate types. This would allow all of the pointers to said types to not need annotation, unlike the current MS model.

In D66610#2028442, @zoecarver wrote:

I don't know of such a flag. My two stage setup actually installs the first stage and then uses the first stage to compile/test the second stage.

Fair enough. I'll try to set up a VM for testing (which I honestly should have done long ago) and install/test this weekend.

In D66610#2028359, @zoecarver wrote:

@davezarzycki what's the configuration flag to get filecheck / lld to use the just-built libcxx? I thought it would be LLVM_ENABLE_LIBCXX but that doesn't appear to work.

In D79673#2028204, @rnk wrote:

Needs a test.

I believe these are only implemented for x86 in LLVM. What happens if you try to use this on non-x86? I wouldn't be surprised if we crash, but we should probably produce a proper error and test it.

4f4ce13944b88bcd678e615d340c21ea1cf5d3ec

This is failing stage two testing on my Fedora 32 (x86-64) Linux box. Can we please revert this or commit a quick fix?

In D66610#2027215, @zoecarver wrote:

Reverted in 26466efe0879dde8772bc336d81fcccaa9514b3a.

Great. Thanks. As a friendly reminder, you’ll need to configure the first stage to use libcxx and also have clang to prefer libcxx, otherwise lld will just use whatever CMake autodetects/decides.

Hello, git bisect of a private stage two builder identified this commit as breaking lld's test suite. Can we either revert this or commit a quick fix to the regular expressions in lld's test suite?

FAIL: lld :: ELF/vs-diagnostics-duplicate-split.s (63239 of 63760)
******************** TEST 'lld :: ELF/vs-diagnostics-duplicate-split.s' FAILED ********************
Script:
--
: 'RUN: at line 2';   /tmp/_update_lc/t/bin/llvm-mc -filetype=obj -triple=x86_64 /home/dave/s/lp/lld/test/ELF/vs-diagnostics-duplicate-split.s -o /tmp/_update_lc/t/tools/lld/test/ELF/Output/vs-diagnostics-duplicate-split.s.tmp.o
: 'RUN: at line 3';   not /tmp/_update_lc/t/bin/ld.lld --vs-diagnostics --shared /tmp/_update_lc/t/tools/lld/test/ELF/Output/vs-diagnostics-duplicate-split.s.tmp.o /tmp/_update_lc/t/tools/lld/test/ELF/Output/vs-diagnostics-duplicate-split.s.tmp.o -o /dev/null 2>&1 | /tmp/_update_lc/t/bin/FileCheck /home/dave/s/lp/lld/test/ELF/vs-diagnostics-duplicate-split.s
--
Exit Code: 1

Hi @ldionne – I've looked a few more tests that use lit's ALLOW_RETRIES feature. I don't think this is a straightforward scenario. While the flawed assumptions are often the same, the fixes are not. Do you want 46 Phab requests? Personally speaking, this seems like one of those cases where the cost of code review discourages bug fixes. If I create decent enough commit messages, would you be open to post-commit review for these test fixes? After all, the tests are already buggy, and we can always revert back to the known buggy version that we have today.

Ran through git clang-format to fix formatting issues that predate these fixes.

Fixed two more tests as an example of how to fix the other thread tests.

Hi @ldionne – Ya, it looks like a lot of those tests need fixing. The "tolerance" goal is within them is fundamentally flawed. These tests are not testing "real time" APIs where one can hopefully reason about precise timing. These APIs are best-effort APIs and on a slow and/or heavily loaded machine, best-effort can get really slow. I don't have the time to fix all of the tests but here is the gist of what needs fixing is twofold:

Ran the patch through clang-format and then manually fixed style problems that clang-format did not fix.

In D78381#2007451, @tpopp wrote:

In D78381#2006266, @davezarzycki wrote:

In D78381#2005219, @ldionne wrote:

I'm going to go ahead and ship this now so I can see whether it breaks anything.

This breaks Fedora 32 (x86_64) building with the system clang/lld (version 10.0):

[0+1] Running all regression tests
llvm-lit: /home/dave/s/lp/libcxxabi/test/lit.cfg:64: note: Using configuration variant: libcxxabi
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/config.py:307: note: inferred use_system_cxx_lib as: None
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/config.py:333: note: inferred use_clang_verify as: True
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/config.py:342: note: enabling thread-safety annotations
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/config.py:487: note: inferred language dialect as: c++2a
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/target_info.py:84: warning: The locale fr_FR.UTF-8 is not supported by your platform. Some tests will be unsupported.
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/target_info.py:84: warning: The locale ru_RU.UTF-8 is not supported by your platform. Some tests will be unsupported.
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/target_info.py:84: warning: The locale zh_CN.UTF-8 is not supported by your platform. Some tests will be unsupported.
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/target_info.py:84: warning: The locale fr_CA.ISO8859-1 is not supported by your platform. Some tests will be unsupported.
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/target_info.py:84: warning: The locale cs_CZ.ISO8859-2 is not supported by your platform. Some tests will be unsupported.
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/config.py:389: note: inferred long_tests as: True
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/config.py:153: note: Using compiler: /usr/bin/clang++
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/config.py:154: note: Using flags: ['-v']
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/config.py:158: note: Using compile flags: ['-Werror=thread-safety', '-DLIBCXXABI_NO_TIMER', '-D_LIBCPP_ENABLE_CXX17_REMOVED_UNEXPECTED_FUNCTIONS', '-funwind-tables', '-std=c++2a', '-nostdinc++', '-I/home/dave/s/lp/libcxx/include', '-I/home/dave/s/lp/libcxxabi/include', '-DSTDC_FORMAT_MACROS', '-DSTDC_LIMIT_MACROS', '-DSTDC_CONSTANT_MACROS', '-I/home/dave/s/lp/libcxx/test/support', '-ftemplate-depth=270']
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/config.py:161: note: Using warnings: ['-Wall', '-Wextra', '-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER', '-Wuser-defined-warnings', '-Wshadow', '-Wno-unused-command-line-argument', '-Wno-attributes', '-Wno-pessimizing-move', '-Wno-c++11-extensions', '-Wno-user-defined-literals', '-Wno-noexcept-type', '-Wsign-compare', '-Wunused-variable', '-Wunused-parameter', '-Wunreachable-code', '-Wno-unused-local-typedef']
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/config.py:162: note: Using link flags: ['-L/tmp/_update_lc/r/./lib64', '-Wl,-rpath,/tmp/_update_lc/r/./lib64', '-L/tmp/_update_lc/r/./lib64', '-Wl,-rpath,/tmp/_update_lc/r/./lib64', '-nodefaultlibs', '/tmp/_update_lc/r/./lib64/libc++.a', '/tmp/_update_lc/r/./lib64/libc++abi.a', '-lm', '-lgcc_s', '-lgcc', '-lpthread', '-lrt', '-lc', '-lgcc_s', '-lgcc']
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/config.py:164: note: Using available_features: ['long_tests', 'fdelayed-template-parsing', 'libc++', 'c++2a', 'diagnose-if-support', 'has-fblocks', '-faligned-allocation', 'clang-10', 'clang', 'locale.en_US.UTF-8', 'linux', 'clang-10.0.0', '-fsized-deallocation', 'thread-safety', 'libcxxabi-has-system-unwinder', 'fcoroutines-ts', 'modules-support', 'clang-10.0']
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/config.py:170: note: Adding environment variables: {}
llvm-lit: /home/dave/s/lp/libcxxabi/test/lit.cfg:77: note: Using the new libc++ testing format
llvm-lit: /home/dave/s/lp/libcxx/test/lit.cfg:49: note: Using configuration variant: libcxx
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/config.py:307: note: inferred use_system_cxx_lib as: None
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/config.py:333: note: inferred use_clang_verify as: True
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/config.py:342: note: enabling thread-safety annotations
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/config.py:487: note: inferred language dialect as: c++2a
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/target_info.py:84: warning: The locale fr_FR.UTF-8 is not supported by your platform. Some tests will be unsupported.
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/target_info.py:84: warning: The locale ru_RU.UTF-8 is not supported by your platform. Some tests will be unsupported.
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/target_info.py:84: warning: The locale zh_CN.UTF-8 is not supported by your platform. Some tests will be unsupported.
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/target_info.py:84: warning: The locale fr_CA.ISO8859-1 is not supported by your platform. Some tests will be unsupported.
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/target_info.py:84: warning: The locale cs_CZ.ISO8859-2 is not supported by your platform. Some tests will be unsupported.
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/config.py:389: note: inferred long_tests as: True
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/config.py:153: note: Using compiler: /usr/bin/clang++
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/config.py:154: note: Using flags: ['-v']
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/config.py:158: note: Using compile flags: ['-Werror=thread-safety', '-std=c++2a', '-include', '/home/dave/s/lp/libcxx/test/support/nasty_macros.h', '-nostdinc++', '-I/home/dave/s/lp/libcxx/include', '-I/tmp/_update_lc/r/projects/libcxx/include/c++build', '-DSTDC_FORMAT_MACROS', '-DSTDC_LIMIT_MACROS', '-DSTDC_CONSTANT_MACROS', '-I/home/dave/s/lp/libcxx/test/support', '-ftemplate-depth=270']
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/config.py:161: note: Using warnings: ['-Wall', '-Wextra', '-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER', '-Wuser-defined-warnings', '-Wshadow', '-Wno-unused-command-line-argument', '-Wno-attributes', '-Wno-pessimizing-move', '-Wno-c++11-extensions', '-Wno-user-defined-literals', '-Wno-noexcept-type', '-Wsign-compare', '-Wunused-variable', '-Wunused-parameter', '-Wunreachable-code', '-Wno-unused-local-typedef']
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/config.py:162: note: Using link flags: ['-L/tmp/_update_lc/r/./lib64', '-Wl,-rpath,/tmp/_update_lc/r/./lib64', '-nodefaultlibs', '-lc++experimental', '/tmp/_update_lc/r/./lib64/libc++.a', '-lc++abi', '-lm', '-lgcc_s', '-lgcc', '-lpthread', '-lrt', '-lc', '-lgcc_s', '-lgcc']
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/config.py:164: note: Using available_features: ['modules-support', 'clang-10.0', 'fdelayed-template-parsing', 'diagnose-if-support', 'has-fblocks', 'clang-10', 'libatomic', '-faligned-allocation', 'clang', 'locale.en_US.UTF-8', 'c++experimental', 'long_tests', 'libc++', 'c++2a', 'linux', 'clang-10.0.0', 'thread-safety', 'fcoroutines-ts', '-fsized-deallocation']
llvm-lit: /home/dave/s/lp/libcxx/utils/libcxx/test/config.py:170: note: Adding environment variables: {}
llvm-lit: /home/dave/s/lp/libcxx/test/lit.cfg:62: note: Using the new libc++ testing format
llvm-lit: /tmp/_update_lc/r/bin/../../../../home/dave/s/lp/llvm/utils/lit/lit/TestingConfig.py:100: fatal: unable to parse config file '/home/dave/s/lp/libcxx/test/libcxx/selftest/dsl/lit.local.cfg', traceback: Traceback (most recent call last):

File "/tmp/_update_lc/r/bin/../../../../home/dave/s/lp/llvm/utils/lit/lit/TestingConfig.py", line 89, in load_from_path
  exec(compile(data, path, 'exec'), cfg_globals, None)
File "/home/dave/s/lp/libcxx/test/libcxx/selftest/dsl/lit.local.cfg", line 13, in <module>
  escaped = [(k.replace('%{', '%{escaped_'), base64.b64encode(v)) for (k, v) in config.substitutions]
File "/home/dave/s/lp/libcxx/test/libcxx/selftest/dsl/lit.local.cfg", line 13, in <listcomp>
  escaped = [(k.replace('%{', '%{escaped_'), base64.b64encode(v)) for (k, v) in config.substitutions]
File "/usr/lib64/python3.8/base64.py", line 58, in b64encode
  encoded = binascii.b2a_base64(s, newline=False)

TypeError: a bytes-like object is required, not 'str'

FAILED: CMakeFiles/check-all

Just a note, this seems due to incompatibilities between python2 and python3. Python2 expects strings like given here while Python3 expects the bytes-like object.

In D78381#2005219, @ldionne wrote:

I'm going to go ahead and ship this now so I can see whether it breaks anything.

In D75068#2004885, @cristian.adam wrote:

In D75068#2004072, @davezarzycki wrote:

Rather than wholly reverting this, I committed a fix: 665471907a5c072c6653a38c35f35e5d54cef220

The problem is that "NOT LIBCLANG_BUILD_STATIC" does not imply PIC, so there is no point in trying to build the SHARED version. Please let me know if I somehow missed something. Thanks!

@thakis has a use case at https://reviews.llvm.org/D74907 building a SHARED libclang with LLVM_ENABLE_PIC set to OFF.

Would the variant if(LLVM_ENABLE_PIC OR (WIN32 AND NOT LIBCLANG_BUILD_STATIC)) work for the Fedora case?

Rather than wholly reverting this, I committed a fix: 665471907a5c072c6653a38c35f35e5d54cef220

This breaks building libclang on Fedora 32 with clang 10.0 and lld 10.0. Do you mind if I revert this tomorrow if a quick fix cannot be found? Here is the relevant diagnostics:

LGTM

FYI – This is generating new warnings with top-of-tree clang. That being said, the warning itself might be faulty:

/usr/local/include/llvm/ADT/STLExtras.h:115:58: warning: HTML tag 'i' requires an end tag [-Wdocumentation-html]
///   * To access the type of an argument: Traits::arg_t<i>
                                                        ~^~
1 warning generated.

I'm abandoning this due to lack of time and the problem being more involved than I thought.

Hi @MaskRay – I was just looking at the source history. I didn't test the old way. As it turns out there isn't a regression, but just some unexplained code in the current clang option parsing. And the -disable-O0-optnone is a useful hint. Thanks! I've been hacking on clang and trying to get the normal inliner pass to run at -O0, but with no luck so far.

Hi @lebedev.ri – Before I add a small new test file, is there an existing one that you know of that would be good to extend?

Thanks!

This breaks the test suite when built "Release" without assertions enabled (Fedora 31 on x86_64). Can we please revert this?
``
FAIL: libc++ :: std/con:q:qtainers/sequences/array/array.creation/to_array.fail.cpp (53333 of 61086)

• TEST 'libc++ :: std/containers/sequences/array/array.creation/to_array.fail.cpp' FAILED ****

Command: ['/usr/bin/clang++', '-o', '/dev/null', '-x', 'c++', '/home/dave/s/lp/libcxx/test/std/containers/sequences/array/array.creation/to_array.fail.cpp', '-c', '-v', '-ftemplate-depth=270', '-fsyntax-only', '-Xclang', '-verify', '-Xclang', '-verify-ignore-unexpected=note', '-ferror-limit=1024', '-Werror=thread-safety', '-std=c++2a', '-include', '/home/dave/s/lp/libcxx/test/support/nasty_macros.h', '-nostdinc++', '-I/home/dave/s/lp/libcxx/include', '-I/tmp/_update_lc/r/projects/libcxx/include/c++build', '-DSTDC_FORMAT_MACROS', '-DSTDC_LIMIT_MACROS', '-D__STDC_CONSTANT_MACROS', '-I/home/dave/s/lp/libcxx/test/support', '-DLIBCXX_FILESYSTEM_STATIC_TEST_ROOT="/home/dave/s/lp/libcxx/test/std/input.output/filesystems/Inputs/static_test_env"', '-DLIBCXX_FILESYSTEM_DYNAMIC_TEST_ROOT="/tmp/_update_lc/r/projects/libcxx/test/filesystem/Output/dynamic_env"', '-DLIBCXX_FILESYSTEM_DYNAMIC_TEST_HELPER="/usr/bin/python /home/dave/s/lp/libcxx/test/support/filesystem_dynamic_test_helper.py"', '-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER', '-Wall', '-Wextra', '-Werror', '-Wuser-defined-warnings', '-Wshadow', '-Wno-unused-command-line-argument', '-Wno-attributes', '-Wno-pessimizing-move', '-Wno-c++11-extensions', '-Wno-user-defined-literals', '-Wno-noexcept-type', '-Wsign-compare', '-Wunused-variable', '-Wunused-parameter', '-Wunreachable-code', '-Wno-error=user-defined-warnings', '-c']
Exit Code: 1

Standard Error:

clang version 9.0.0 (Fedora 9.0.0-1.fc31)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/9
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/9
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
"/usr/bin/clang-9" -cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only -disable-free -disable-llvm-verifier -discard-value-names -main-file-name to_array.fail.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -v -nostdinc++ -resource-dir /usr/lib64/clang/9.0.0 -include /home/dave/s/lp/libcxx/test/support/nasty_macros.h -I /home/dave/s/lp/libcxx/include -I /tmp/_update_lc/r/projects/libcxx/include/c++build -D STDC_FORMAT_MACROS -D STDC_LIMIT_MACROS -D __STDC_CONSTANT_MACROS -I /home/dave/s/lp/libcxx/test/support -D "LIBCXX_FILESYSTEM_STATIC_TEST_ROOT=\"/home/dave/s/lp/libcxx/test/std/input.output/filesystems/Inputs/static_test_env\"" -D "LIBCXX_FILESYSTEM_DYNAMIC_TEST_ROOT=\"/tmp/_update_lc/r/projects/libcxx/test/filesystem/Output/dynamic_env\"" -D "LIBCXX_FILESYSTEM_DYNAMIC_TEST_HELPER=\"/usr/bin/python /home/dave/s/lp/libcxx/test/support/filesystem_dynamic_test_helper.py\"" -D _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -internal-isystem /usr/local/include -internal-isystem /usr/lib64/clang/9.0.0/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -Werror=thread-safety -Wall -Wextra -Werror -Wuser-defined-warnings -Wshadow -Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move -Wno-c++11-extensions -Wno-user-defined-literals -Wno-noexcept-type -Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code -Wno-error=user-defined-warnings -std=c++2a -fdeprecated-macro -fdebug-compilation-dir /tmp/_update_lc/r -ftemplate-depth 270 -ferror-limit 1024 -fmessage-length 0 -fno-implicit-modules -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -verify -verify-ignore-unexpected=note -faddrsig -x c++ /home/dave/s/lp/libcxx/test/std/containers/sequences/array/array.creation/to_array.fail.cpp
clang -cc1 version 9.0.0 based upon LLVM 9.0.0 default target x86_64-unknown-linux-gnu
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
/home/dave/s/lp/libcxx/include
/tmp/_update_lc/r/projects/libcxx/include/c++build
/home/dave/s/lp/libcxx/test/support
/usr/local/include
/usr/lib64/clang/9.0.0/include
/usr/include
End of search list.
error: 'error' diagnostics expected but not seen:

File /home/dave/s/lp/libcxx/test/std/containers/sequences/array/array.creation/to_array.fail.cpp Line 20: here
File /home/dave/s/lp/libcxx/test/std/containers/sequences/array/array.creation/to_array.fail.cpp Line 25: here
File /home/dave/s/lp/libcxx/test/std/containers/sequences/array/array.creation/to_array.fail.cpp Line 30: here

error: 'error' diagnostics seen but not expected:

File /home/dave/s/lp/libcxx/include/array Line 499: static_assert failed due to requirement '!is_array_v<char [6]>' "[array.creation]/1: to_array does not accept multidimensional arrays."
File /home/dave/s/lp/libcxx/include/array Line 502: static_assert failed due to requirement 'is_constructible_v<char [6], char (&)[6]>' "[array.creation]/1: to_array requires copy constructible elements."
File /home/dave/s/lp/libcxx/include/array Line 487: cannot initialize an array element of type 'char' with an lvalue of type 'char [6]'
File /home/dave/s/lp/libcxx/include/array Line 487: cannot initialize an array element of type 'char' with an lvalue of type 'char [6]'
File /home/dave/s/lp/libcxx/include/array Line 487: cannot initialize an array element of type 'char' with an lvalue of type 'char [6]'
File /home/dave/s/lp/libcxx/include/array Line 487: suggest braces around initialization of subobject
File /home/dave/s/lp/libcxx/include/array Line 502: static_assert failed due to requirement 'is_constructible_v<MoveOnly, MoveOnly &>' "[array.creation]/1: to_array requires copy constructible elements."
File /home/dave/s/lp/libcxx/include/array Line 487: calling a private constructor of class 'MoveOnly'
File /home/dave/s/lp/libcxx/include/array Line 514: static_assert failed due to requirement 'is_move_constructible_v<const MoveOnly>' "[array.creation]/4: to_array requires move constructible elements."
Line 493: calling a private constructor of class 'MoveOnly'

13 errors generated.

5dda92fcb0ce9206f831aa7cddf24421dcf044d7