| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[libc++] Remove "// -*- C++ -*-" comments from all .cpp files. NFCI. Even if these comments have a benefit in .h files (for editors that care about language but can't be configured to treat .h as C++ code), they certainly have no benefit for files with the .cpp extension. Discussed in D110794. | 4 年前 | |
[libc++] Remove "// -*- C++ -*-" comments from all .cpp files. NFCI. Even if these comments have a benefit in .h files (for editors that care about language but can't be configured to treat .h as C++ code), they certainly have no benefit for files with the .cpp extension. Discussed in D110794. | 4 年前 | |
[libc++] Use named Lit features to flag back-deployment XFAILs Instead of writing something like XFAIL: use_system_cxx_lib && target=... to XFAIL back-deployment tests, introduce named Lit features like availability-shared_mutex-missing to represent those. This makes the XFAIL annotations leaner, and solves the problem of XFAIL comments potentially getting out of sync. This would also make it easier for another vendor to add their own annotations to the test suite by simply changing how the feature is defined for their OS releases, instead of having to modify hundreds of tests to add repetitive annotations. This doesn't touch *all* annotations -- only annotations that were widely duplicated are given named features (e.g. when filesystem or shared_mutex were introduced). I still think it probably doesn't make sense to have a named feature for every single fix we make to the dylib. This is in essence a revert of 2659663, but since then the test suite has changed significantly. Back when I did 2659663, the configuration files we have for the test suite right now were being bootstrapped and it wasn't clear how to provide these features for back-deployment in that context. Since then, we have a streamlined way of defining these features in features.py and that doesn't impact the ability for a configuration file to stay minimal. The original motivation for this change was that I am about to propose a change that would touch essentially all XFAIL annotations for back-deployment in the test suite, and this greatly reduces the number of lines changed by that upcoming change, in addition to making the test suite generally better. Differential Revision: https://reviews.llvm.org/D146359 | 3 年前 | |
[libc++] Use named Lit features to flag back-deployment XFAILs Instead of writing something like XFAIL: use_system_cxx_lib && target=... to XFAIL back-deployment tests, introduce named Lit features like availability-shared_mutex-missing to represent those. This makes the XFAIL annotations leaner, and solves the problem of XFAIL comments potentially getting out of sync. This would also make it easier for another vendor to add their own annotations to the test suite by simply changing how the feature is defined for their OS releases, instead of having to modify hundreds of tests to add repetitive annotations. This doesn't touch *all* annotations -- only annotations that were widely duplicated are given named features (e.g. when filesystem or shared_mutex were introduced). I still think it probably doesn't make sense to have a named feature for every single fix we make to the dylib. This is in essence a revert of 2659663, but since then the test suite has changed significantly. Back when I did 2659663, the configuration files we have for the test suite right now were being bootstrapped and it wasn't clear how to provide these features for back-deployment in that context. Since then, we have a streamlined way of defining these features in features.py and that doesn't impact the ability for a configuration file to stay minimal. The original motivation for this change was that I am about to propose a change that would touch essentially all XFAIL annotations for back-deployment in the test suite, and this greatly reduces the number of lines changed by that upcoming change, in addition to making the test suite generally better. Differential Revision: https://reviews.llvm.org/D146359 | 3 年前 | |
[libc++] Remove "// -*- C++ -*-" comments from all .cpp files. NFCI. Even if these comments have a benefit in .h files (for editors that care about language but can't be configured to treat .h as C++ code), they certainly have no benefit for files with the .cpp extension. Discussed in D110794. | 4 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 |