Changes in what.pass.cpp

a7f9895c - [runtimes] Rename various libcpp-has-no-XYZ Lit features to just no-XYZ

Thu, 26 May 2022 15:49:47 +0000

[runtimes] Rename various libcpp-has-no-XYZ Lit features to just no-XYZSince those features are general properties of the environment, it makessense to use them from libc++abi too, and so the name libcpp-has-no-xxxdoesn't make sense.Differential Revision: https://reviews.llvm.org/D126482 List of files: /llvm-project-15.0.7/libcxx/test/std/thread/futures/futures.future_error/what.pass.cpp

c360553c - [runtimes] Simplify how we specify XFAIL & friends based on the triple

Fri, 18 Jun 2021 17:33:14 +0000

[runtimes] Simplify how we specify XFAIL & friends based on the tripleNow that Lit supports regular expressions inside XFAIL & friends, it ismuch easier to write Lit annotations based on the triple.Differential Revision: https://reviews.llvm.org/D104747 List of files: /llvm-project-15.0.7/libcxx/test/std/thread/futures/futures.future_error/what.pass.cpp

74d096e5 - [libc++] Move handling of the target triple to the DSL

Fri, 07 May 2021 14:15:36 +0000

[libc++] Move handling of the target triple to the DSLThis fixes a long standing issue where the triple is not always setconsistently in all configurations. This change also moves theback-deployment Lit features to using the proper target tripleinstead of using something ad-hoc.This will be necessary for using from scratch Lit configuration filesin both normal testing and back-deployment testing.Differential Revision: https://reviews.llvm.org/D102012 List of files: /llvm-project-15.0.7/libcxx/test/std/thread/futures/futures.future_error/what.pass.cpp

7149bb70 - [libc++] NFC: Clean up a lot of old Lit features

Fri, 10 Apr 2020 20:14:10 +0000

[libc++] NFC: Clean up a lot of old Lit featuresThe libc++ test suite has a lot of old Lit features used to XFAIL testsand mark them as UNSUPPORTED. Many of them are to workaround problems onold compilers or old platforms. As time goes by, it is good to go andclean those up to simplify the configuration of the test suite, and alsoto reflect the testing reality. It's not useful to have markup that givesthe impression that e.g. clang-3.3 is supported, when we don't reallytest on it anymore (and hence several new tests probably don't have thenecessary markup on them). List of files: /llvm-project-15.0.7/libcxx/test/std/thread/futures/futures.future_error/what.pass.cpp

2df59c50 - Support tests in freestanding

Mon, 04 Feb 2019 20:31:13 +0000

Support tests in freestandingSummary:Freestanding is *weird*. The standard allows it to differ in a bunch of oddmanners from regular C++, and the committee would like to improve thatsituation. I'd like to make libc++ behave better with what freestanding shouldbe, so that it can be a tool we use in improving the standard. To do that weneed to try stuff out, both with "freestanding the language mode" and"freestanding the library subset".Let's start with the super basic: run the libc++ tests in freestanding, usingclang as the compiler, and see what works. The easiest hack to do this:In utils/libcxx/test/config.py add: self.cxx.compile_flags += ['-ffreestanding']Run the tests and they all fail.Why? Because in freestanding `main` isn't special. This "not special" propertyhas two effects: main doesn't get mangled, and main isn't allowed to omit its`return` statement. The first means main gets mangled and the linker can'tcreate a valid executable for us to test. The second means we spew out warnings(ew) and the compiler doesn't insert the `return` we omitted, and main justfalls of the end and does whatever undefined behavior (if you're luck, ud2leading to non-zero return code).Let's start my work with the basics. This patch changes all libc++ tests todeclare `main` as `int main(int, char**` so it mangles consistently (enabling usto declare another `extern "C"` main for freestanding which calls the mangledone), and adds `return 0;` to all places where it was missing. This touches 6124files, and I apologize.The former was done with The Magic Of Sed.The later was done with a (not quite correct but decent) clang tool: https://gist.github.com/jfbastien/793819ff360baa845483dde81170feedThis works for most tests, though I did have to adjust a few places when e.g.the test runs with `-x c`, macros are used for main (such as for the filesystemtests), etc.Once this is in we can create a freestanding bot which will prevent furtherregressions. After that, we can start the real work of supporting C++freestanding fairly well in libc++.Reviewers: ldionne, mclow.lists, EricWFSubscribers: christof, jkorous, dexonsmith, arphaman, miyuki, libcxx-commitsDifferential Revision: https://reviews.llvm.org/D57624llvm-svn: 353086 List of files: /llvm-project-15.0.7/libcxx/test/std/thread/futures/futures.future_error/what.pass.cpp

57b08b09 - Update more file headers across all of the LLVM projects in the monorepo

Sat, 19 Jan 2019 10:56:40 +0000

Update more file headers across all of the LLVM projects in the monorepoto reflect the new license. These used slightly different spellings thatdefeated my regular expressions.We understand that people may be surprised that we're moving the headerentirely to discuss the new license. We checked this carefully with theFoundation's lawyer and we believe this is the correct approach.Essentially, all code in the project is now made available by the LLVMproject under our new license, so you will see that the license headersinclude that license only. Some of our contributors have contributedcode under our old license, and accordingly, we have retained a copy ofour old license notice in the top-level files in each project andrepository.llvm-svn: 351648 List of files: /llvm-project-15.0.7/libcxx/test/std/thread/futures/futures.future_error/what.pass.cpp

e9c66ad9 - Add markup for libc++ dylib availability

Thu, 04 May 2017 17:08:54 +0000

Add markup for libc++ dylib availabilityLibc++ is used as a system library on macOS and iOS (amongst others). In orderfor users to be able to compile a binary that is intended to be deployed to anolder version of the platform, clang provides theavailability attribute _that can be placed on declarations to describe the lifecycle of a symbol in thelibrary.See docs/DesignDocs/AvailabilityMarkup.rst for more information.Differential Revision: https://reviews.llvm.org/D31739llvm-svn: 302172 List of files: /llvm-project-15.0.7/libcxx/test/std/thread/futures/futures.future_error/what.pass.cpp

f8764e30 - Add deployment knobs to tests (for Apple platforms)

Wed, 15 Mar 2017 00:59:54 +0000

Add deployment knobs to tests (for Apple platforms)The tests for libc++ specify -target on the command-line to thecompiler, but this is problematic for a few reasons.Firstly, the -target option isn't supported on Apple platforms. Partsof the triple get dropped and ignored. Instead, software should becompiled with a combination of the -arch and -m-version-minoptions.Secondly, the generic "darwin" target references a kernel versioninstead of a platform version. Each platform has its own independentversions (with different versions of libc++.1.dylib), independent of theversion of the Darwin kernel.This commit adds support to the LIT infrastructure for testing againstApple platforms using -arch and -platform options.If the host is not on OS X, or the compiler type is not clang or apple-clang, then this commit has NFC.If the host is on OS X and --param=target_triple=... is specified, then a warning is emitted to use arch and platform instead. Besides the warning, there's NFC.If the host is on OS X and *no* target-triple is specified, then use the new deployment target logic. This uses two new lit parameters, --param=arch= and --param=platform=. has the form [].By default, arch is auto-detected from clang -dumpmachine, and platform is "macosx".If the platform doesn't have a version:For "macosx", the version is auto-detected from the host system using sw_vers. This may give a different version than the SDK, since new SDKs can be installed on older hosts.Otherwise, the version is auto-detected from the SDK version using xcrun --show-sdk-path.-arch -m-version-min= is added to the compiler flags.The target triple is computed as -apple-. It is *not* passed to clang, but it is available for XFAIL and UNSUPPORTED (as is with_system_cxx_lib=).For convenience, apple-darwin and -apple-darwin are added to the set of available features.There were a number of tests marked to XFAIL on x86_64-apple-darwin11and x86_64-apple-darwin12. I updated these tox86_64-apple-macosx10.7 and x86_64-apple-macosx10.8.llvm-svn: 297798 List of files: /llvm-project-15.0.7/libcxx/test/std/thread/futures/futures.future_error/what.pass.cpp

64bac8b5 - [libcxx] [test] D26625: future_error::what() is implementation-defined.

Tue, 15 Nov 2016 17:00:32 +0000

[libcxx] [test] D26625: future_error::what() is implementation-defined.llvm-svn: 286983 List of files: /llvm-project-15.0.7/libcxx/test/std/thread/futures/futures.future_error/what.pass.cpp

eb7b5e74 - Rename system_lib -> system_cxx_lib. NFC

Wed, 14 Jan 2015 23:38:12 +0000

Rename system_lib -> system_cxx_lib. NFCllvm-svn: 226061 List of files: /llvm-project-15.0.7/libcxx/test/std/thread/futures/futures.future_error/what.pass.cpp

5a83710e - Move test into test/std subdirectory.

Sat, 20 Dec 2014 01:40:03 +0000

Move test into test/std subdirectory.llvm-svn: 224658 List of files: /llvm-project-15.0.7/libcxx/test/std/thread/futures/futures.future_error/what.pass.cpp