The test will fail if libc++ starts to use a lambda in `<array>`. This
will become the case because
- libc++'s `array::fill` uses `std::fill_n`, and
- `std::fill_n` is to be optimized for segment iterators, and
- the natural approach for such optimization uses lambdas.
Until ASTImport of `clang::LambdaExpr` nodes gets properly fix, this
will need to be skipped.
This reverts commit 76bd5da3248fd4affedfefec3b2a3e1acbe0a94a.
These were originally skipped for
https://github.com/llvm/llvm-project/issues/137046 because they were
failing on Fuchsia buildbots.
I couldn't locally reproduce the Linux failures from back then (and
maybe they have been fixed by something else since then).
We want to re-enable these tests because they are one of the few API
tests in the `libcxx` category that we skip on Linux. So the libc++
pre-merge CI doesn't catch these test failures. To avoid churn caused by
this missing coverage, it would be great if we ran these on Linux again.
This reverts commit 2b4b3fd03f716b9ddbb2a69ccfbe144312bedd12.
Turns out the CI still fails with this test enabled:
```
11:08:50 File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/commands/expression/import-std-module/queue/TestQueueFromStdModule.py", line 37, in test
11:08:50 self.expect_expr(
11:08:50 File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2571, in expect_expr
11:08:50 value_check.check_value(self, eval_result, str(eval_result))
11:08:50 File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 301, in check_value
11:08:50 test_base.assertSuccess(val.GetError())
11:08:50 File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2606, in assertSuccess
11:08:50 self.fail(self._formatMessage(msg, "'{}' is not success".format(error)))
11:08:50 AssertionError: 'error: /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/usr/include/module.modulemap:93:11: header 'stdarg.h' not found
11:08:50 93 | header "stdarg.h" // note: supplied by the compiler
11:08:50 | ^
11:08:50 /Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/lib/clang/22/include/stdint.h:56:16: submodule of top-level module 'Darwin' implicitly imported here
11:08:50 56 | # include_next <stdint.h>
11:08:50 | ^
11:08:50 error: While building module 'std' imported from <lldb wrapper prefix>:42:
```
Failing on the macOS matrix bot for Clang-15:
```
07:38:40 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/commands/expression/import-std-module/queue/TestQueueFromStdModule.py", line 38, in test
07:38:40 self.expect_expr(
07:38:40 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2571, in expect_expr
07:38:40 value_check.check_value(self, eval_result, str(eval_result))
07:38:40 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 301, in check_value
07:38:40 test_base.assertSuccess(val.GetError())
07:38:40 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2606, in assertSuccess
07:38:40 self.fail(self._formatMessage(msg, "'{}' is not success".format(error)))
07:38:40 AssertionError: 'error: /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/usr/include/module.modulemap:93:11: header 'stdarg.h' not found
07:38:40 93 | header "stdarg.h" // note: supplied by the compiler
07:38:40 | ^
07:38:40 /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/clang_1501_build/include/c++/v1/ctype.h:38:15: submodule of top-level module 'Darwin' implicitly imported here
07:38:40 38 | #include_next <ctype.h>
07:38:40 | ^
07:38:40 error: While building module 'std' imported from <lldb wrapper prefix>:42:
```
https://github.com/llvm/llvm-project/pull/144913 was reverted because
some of the Darwin tests were failing on SDKs prior to `15.0`.
Only the x86 bots run on macOS `14.0`. The aarch64 ones run on macOS
`15.0`.
In this patch, we deactivate the failing Darwin tests on older SDKs
(prior to `15.0`).
The test checks specific compiler version to determine the output.
However, the compiler version string is always set to 15.0.0 for our
local build. Remove this check and use regex match instead.
## Test Plan
```
./bin/llvm-lit -sva /home/wanyi/llvm-sand/external/llvm-project/lldb/test/API/commands/expression/import-std-module/vector-of-vectors/TestVectorOfVectorsFromStdModule.py
...
Skipping the following test categories: ['dsym', 'gmodules', 'debugserver', 'objc']
--
Command Output (stderr):
--
UNSUPPORTED: LLDB (/home/wanyi/llvm-sand/build/Release+Distribution/fbcode-x86_64/toolchain/bin/clang-x86_64) :: test_dsym (TestVectorOfVectorsFromStdModule.TestVectorOfVectors) (test case does not fall in any category of interest for this run)
PASS: LLDB (/home/wanyi/llvm-sand/build/Release+Distribution/fbcode-x86_64/toolchain/bin/clang-x86_64) :: test_dwarf (TestVectorOfVectorsFromStdModule.TestVectorOfVectors)
PASS: LLDB (/home/wanyi/llvm-sand/build/Release+Distribution/fbcode-x86_64/toolchain/bin/clang-x86_64) :: test_dwo (TestVectorOfVectorsFromStdModule.TestVectorOfVectors)
----------------------------------------------------------------------
Ran 3 tests in 4.636s
OK (skipped=1)
--
********************
Testing Time: 4.97s
Total Discovered Tests: 1
Passed: 1 (100.00%)
```
Some tests from 'import-std-module' used to fail on the builder
https://lab.llvm.org/staging/#/builders/195/builds/4470,
since libcxx is set up to be linked statically with test binaries
on it.
Thus, they were temporarily disabled in #112530. Here, this commit
is reverted.
Jitted expressions from the tests try to call __libcpp_verbose_abort
function that is not present in the process image, which causes
the failure.
Here, this symbol is explicitly referenced from the test source files.
This is a revert of b1fcc1840c312472cb9ccb8c4e5e02ca13b31113.
These tests weren't working on Ubuntu 22.04 or Fedora 37-40. I'm not
sure exactly why, but it seems like they may be incompatible with
libstdc++. Also, despite the fact that the tests were using the system
libstdc++, the tests were only run when libcxx was enabled.
I tested this with a RelWithDebInfo build and the tests passed.
Fixes#106475
This makes use of the changes introduced in D134604, in order to
instantiate alias templates witn a final sugared substitution.
This comes at no additional relevant cost.
Since we don't track / unique them in specializations, we wouldn't be
able to resugar them later anyway.
Differential Revision: https://reviews.llvm.org/D136565
Started failing since D101206, but root-cause is unclear. It's
definitely not an issue with th libc++ patch itself however. So disable
the test until we know what's going on.
The error message "Couldn't lookup symbols" emitted from IRExecutionUnit
is grammatically incorrect. "Lookup" is noun when spelled without a
space. Update the error message to use the verb "look up" instead.
These tests started failing on the public build-bots recently
with following error:
```
AssertionError: 'error: Couldn't lookup symbols:
__ZNSt3__122__libcpp_verbose_abortEPKcz
' is not success
```
We've seen this previously when the SDKs we used to compile the
`std` module differ from the test program.
(see D146714, rdar://107052293, D139361, rdar://102427461)
Skip these tests on older MacOS versions for now.
This is possibly related to the recent `std` module changes in D144322.
rdar://113227172
Differential Revision: https://reviews.llvm.org/D156827
This is an ongoing series of commits that are reformatting our Python
code. Reformatting is done with `black` (23.1.0).
If you end up having problems merging this commit because you have made
changes to a python file, the best way to handle that is to run `git
checkout --ours <yourfile>` and then reformat it with black.
RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Differential revision: https://reviews.llvm.org/D151460
**Summary**
The compiler version check wouldn't make sense for non-GCC
compilers, so check for the compiler too.
Differential Revision: https://reviews.llvm.org/D143656
Set compiler_versions on these tests, as they fail if tested on lower compiler
versions versions.
Differential Revision: https://reviews.llvm.org/D142513
The tests in this patch expose failures of LLDBs expression evaluator
when a standard library is compiled with debug symbols. This is the case
for RelWithDebugInfo builds of llvm-project (with libcxx).
Until these bugs are fixed, we force these tests to use the system's
standard library.
Differential Revision: https://reviews.llvm.org/D139361
The libc++ data formatter for `std::shared_ptr` allows any namespace, but the test asserts that it must be the default `__1` namespace. Relax the regex to allow anything that looks like `__.*` (although we use `__[^:]*` so we don't match arbitrarily long text).
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D129898
This makes use of the changes introduced in D134604, in order to
instantiate alias templates witn a final sugared substitution.
This comes at no additional relevant cost.
Since we don't track / unique them in specializations, we wouldn't be
able to resugar them later anyway.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D136565
This patch reverts
- commit d4b1964f0554046b1e64908e5c1cd701b25f4c9e
- commit 59f0827e2cf3755834620e7e0b6d946832440f80([clang] Instantiate alias templates with sugar)
As it makes clang fail to pass some code it used to compile.
See comments: https://reviews.llvm.org/D136564#3891065
This makes use of the changes introduced in D134604, in order to
instantiate alias templates witn a final sugared substitution.
This comes at no additional relevant cost.
Since we don't track / unique them in specializations, we wouldn't be
able to resugar them later anyway.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D136565
This makes use of the changes introduced in D134604, in order to
instantiate alias templates witn a final sugared substitution.
This comes at no additional relevant cost.
Since we don't track / unique them in specializations, we wouldn't be
able to resugar them later anyway.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D136565
These tests have begun failing starting with commit
`69a6417406a1b0316a1fa6aeb63339d0e1d2abbd`, which
added a new `import` to `ASTNodeImporter::VisitTypedefType`.
This trips an assertion in following way:
1. When creating a persistent variable for the result we call `CopyType`
(in `DeportType`) under a `CompleteTagDeclsScope` (which is supposed to complete all
decls newly imported in the `CopyType` call).
2. During `CopyType` we call `ASTNodeImporter::VisitTypedefType`
3. This now has a second import call on the desugared type
4. In `ASTImporterDelegate::ImportImpl` we will now try to import a decl
that we originally got from the `std` module (which means it has no valid origin).
But since we’re doing this under a CompleteTagDeclsScope, the
`NewDeclListener::NewDeclImported` adds the decl to the list of decls to
complete after the `CopyType` call. But this list shouldn’t contain decls
with invalid origins because we assert this in `~CompleteTagDeclsScope`, which
is where the tests crash.
We suspect that we previously didn’t see this assert trigger because by the time
we create the result variable we are using an AST whose decls all have
a valid debug-info origin (constructed with the help of the std module).
So we never expected decls from modules to be imported under
`CompleteTagDeclsScope` without a m_sema available (which is the case by
the time we get to `DeportType`). Since there is no `m_sema` available,
`CxxModuleHandler::Import` trivially returns and the decls don’t get added
to the `m_decls_to_ignore` list and count as "newly imported decls".
Skip this test for now until we have a fix or the origin tracking gets
refactored (see https://reviews.llvm.org/D101950).
Differential Revision: https://reviews.llvm.org/D135178
A recent libcxx change renamed all internal variables starting with
`__`. As such, `std::reverse_iterator::__t` was renamed to
`std::reverse_iterator::__t_`. This breaks the `import-std-module`
tests with newer libcxx versions. Since this variable is deprecated
in libcxx anyway, this patch simply removes the explicit `ValueCheck`
on the variable name. We don't lose any interesting test-case here
since the purpose of the test is to see if we can call functions
from the `std` module.
We can now re-enable the tests on Darwin for all buildbot Clang
compiler variants.
Differential Revision: https://reviews.llvm.org/D134727
This commit improves upon cc0b5ebf7fc8, which added support for
specifying which libcxx to use when testing LLDB. That patch honored
requests by tests that had `USE_LIBCPP=1` defined in their makefiles.
Now, we also use a non-default libcxx if all conditions below are true:
1. The test is not explicitly requesting the use of libstdcpp
(USE_LIBSTDCPP=1).
2. The test is not explicitly requesting the use of the system's
library (USE_SYSTEM_STDLIB=1).
3. A path to libcxx was either provided by the user through CMake flags
or libcxx was built together with LLDB.
Condition (2) is new and introduced in this patch in order to support
tests that are either:
* Cross-platform (such as API/macosx/macCatalyst and
API/tools/lldb-server). The just-built libcxx is usually not built for
platforms other than the host's.
* Cross-language (such as API/lang/objc/exceptions). In this case, the
Objective C runtime throws an exceptions that always goes through the
system's libcxx, instead of the just built libcxx. Fixing this would
require either changing the install-name of the just built libcxx in Mac
systems, or tuning the DYLD_LIBRARY_PATH variable at runtime.
Some other tests exposes limitations of LLDB when running with a debug
standard library. TestDbgInfoContentForwardLists had an assertion
removed, as it was checking for buggy LLDB behavior (which now
crashes). TestFixIts had a variable renamed, as the old name clashes
with a standard library name when debug info is present. This is a known
issue: https://github.com/llvm/llvm-project/issues/34391.
For `TestSBModule`, the way the "main" module is found was changed to
look for the "a.out" module, instead of relying on the index being 0. In
some systems, the index 0 is dyld when a custom standard library is
used.
Differential Revision: https://reviews.llvm.org/D132940
These tests started failing on green dragon after a configuration change that compiles tests using the just-built libcxx. We may need to force the system libcxx here, or change LLDB to import the std module from the just-built libcxx, too.
This commit improves upon cc0b5ebf7fc8, which added support for
specifying which libcxx to use when testing LLDB. That patch honored
requests by tests that had `USE_LIBCPP=1` defined in their makefiles.
Now, we also use a non-default libcxx if all conditions below are true:
1. The test is not explicitly requesting the use of libstdcpp
(USE_LIBSTDCPP=1).
2. The test is not explicitly requesting the use of the system's
library (USE_SYSTEM_STDLIB=1).
3. A path to libcxx was either provided by the user through CMake flags
or libcxx was built together with LLDB.
Condition (2) is new and introduced in this patch in order to support
tests that are either:
* Cross-platform (such as API/macosx/macCatalyst and
API/tools/lldb-server). The just-built libcxx is usually not built for
platforms other than the host's.
* Cross-language (such as API/lang/objc/exceptions). In this case, the
Objective C runtime throws an exceptions that always goes through the
system's libcxx, instead of the just built libcxx. Fixing this would
require either changing the install-name of the just built libcxx in Mac
systems, or tuning the DYLD_LIBRARY_PATH variable at runtime.
Some other tests exposes limitations of LLDB when running with a debug
standard library. TestDbgInfoContentForwardLists had an assertion
removed, as it was checking for buggy LLDB behavior (which now
crashes). TestFixIts had a variable renamed, as the old name clashes
with a standard library name when debug info is present. This is a known
issue: https://github.com/llvm/llvm-project/issues/34391.
For `TestSBModule`, the way the "main" module is found was changed to
look for the "a.out" module, instead of relying on the index being 0. In
some systems, the index 0 is dyld when a custom standard library is
used.
Differential Revision: https://reviews.llvm.org/D132940
Without this patch, clang will not wrap in an ElaboratedType node types written
without a keyword and nested name qualifier, which goes against the intent that
we should produce an AST which retains enough details to recover how things are
written.
The lack of this sugar is incompatible with the intent of the type printer
default policy, which is to print types as written, but to fall back and print
them fully qualified when they are desugared.
An ElaboratedTypeLoc without keyword / NNS uses no storage by itself, but still
requires pointer alignment due to pre-existing bug in the TypeLoc buffer
handling.
---
Troubleshooting list to deal with any breakage seen with this patch:
1) The most likely effect one would see by this patch is a change in how
a type is printed. The type printer will, by design and default,
print types as written. There are customization options there, but
not that many, and they mainly apply to how to print a type that we
somehow failed to track how it was written. This patch fixes a
problem where we failed to distinguish between a type
that was written without any elaborated-type qualifiers,
such as a 'struct'/'class' tags and name spacifiers such as 'std::',
and one that has been stripped of any 'metadata' that identifies such,
the so called canonical types.
Example:
```
namespace foo {
struct A {};
A a;
};
```
If one were to print the type of `foo::a`, prior to this patch, this
would result in `foo::A`. This is how the type printer would have,
by default, printed the canonical type of A as well.
As soon as you add any name qualifiers to A, the type printer would
suddenly start accurately printing the type as written. This patch
will make it print it accurately even when written without
qualifiers, so we will just print `A` for the initial example, as
the user did not really write that `foo::` namespace qualifier.
2) This patch could expose a bug in some AST matcher. Matching types
is harder to get right when there is sugar involved. For example,
if you want to match a type against being a pointer to some type A,
then you have to account for getting a type that is sugar for a
pointer to A, or being a pointer to sugar to A, or both! Usually
you would get the second part wrong, and this would work for a
very simple test where you don't use any name qualifiers, but
you would discover is broken when you do. The usual fix is to
either use the matcher which strips sugar, which is annoying
to use as for example if you match an N level pointer, you have
to put N+1 such matchers in there, beginning to end and between
all those levels. But in a lot of cases, if the property you want
to match is present in the canonical type, it's easier and faster
to just match on that... This goes with what is said in 1), if
you want to match against the name of a type, and you want
the name string to be something stable, perhaps matching on
the name of the canonical type is the better choice.
3) This patch could expose a bug in how you get the source range of some
TypeLoc. For some reason, a lot of code is using getLocalSourceRange(),
which only looks at the given TypeLoc node. This patch introduces a new,
and more common TypeLoc node which contains no source locations on itself.
This is not an inovation here, and some other, more rare TypeLoc nodes could
also have this property, but if you use getLocalSourceRange on them, it's not
going to return any valid locations, because it doesn't have any. The right fix
here is to always use getSourceRange() or getBeginLoc/getEndLoc which will dive
into the inner TypeLoc to get the source range if it doesn't find it on the
top level one. You can use getLocalSourceRange if you are really into
micro-optimizations and you have some outside knowledge that the TypeLocs you are
dealing with will always include some source location.
4) Exposed a bug somewhere in the use of the normal clang type class API, where you
have some type, you want to see if that type is some particular kind, you try a
`dyn_cast` such as `dyn_cast<TypedefType>` and that fails because now you have an
ElaboratedType which has a TypeDefType inside of it, which is what you wanted to match.
Again, like 2), this would usually have been tested poorly with some simple tests with
no qualifications, and would have been broken had there been any other kind of type sugar,
be it an ElaboratedType or a TemplateSpecializationType or a SubstTemplateParmType.
The usual fix here is to use `getAs` instead of `dyn_cast`, which will look deeper
into the type. Or use `getAsAdjusted` when dealing with TypeLocs.
For some reason the API is inconsistent there and on TypeLocs getAs behaves like a dyn_cast.
5) It could be a bug in this patch perhaps.
Let me know if you need any help!
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D112374
TestStackFromStdModule.py started failing due to f4fb72e6d4ce
(https://reviews.llvm.org/D128146), with a clang assertion failure:
assert(isa<InjectedClassNameType>(Decl->TypeForDecl))
Eliminate boilerplate of having each test manually assign to `mydir` by calling
`compute_mydir` in lldbtest.py.
Differential Revision: https://reviews.llvm.org/D128077
