| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 372737
|
|
|
|
| |
llvm-svn: 372736
|
|
|
|
|
|
| |
That's what we actually want to do. Might fix the Windows bot.
llvm-svn: 372729
|
|
|
|
| |
llvm-svn: 372724
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
compiled
Summary:
At the moment, when trying to import the `std` module in LLDB, we look at the imported modules used in the compiled program
and try to infer the Clang configuration we need from the DWARF module-import. That was the initial idea but turned out to
cause a few problems or inconveniences:
* It requires that users compile their programs with C++ modules. Given how experimental C++ modules are makes this feature inaccessible
for many users. Also it means that people can't just get the benefits of this feature for free when we activate it by default
(and we can't just close all the associated bug reports).
* Relying on DWARF's imported module tags (that are only emitted by default on macOS) means this can only be used when using DWARF (and with -glldb on Linux).
* We essentially hardcoded the C standard library paths on some platforms (Linux) or just couldn't support this feature on other platforms (macOS).
This patch drops the whole idea of looking at the imported module DWARF tags and instead just uses the support files of the compilation unit.
If we look at the support files and see file paths that indicate where the C standard library and libc++ are, we can just create the module
configuration this information. This fixes all the problems above which means we can enable all the tests now on Linux, macOS and with other debug information
than what we currently had. The only debug information specific code is now the iteration over external type module when -gmodules is used (as `std` and also the
`Darwin` module are their own external type module with their own files).
The meat of this patch is the CppModuleConfiguration which looks at the file paths from the compilation unit and then figures out the include paths
based on those paths. It's quite conservative in that it only enables modules if we find a single C library and single libc++ library. It's still missing some
test mode where we try to compile an expression before we actually activate the config for the user (which probably also needs some caching mechanism),
but for now it works and makes the feature usable.
Reviewers: aprantl, shafik, jdoerfert
Reviewed By: aprantl
Subscribers: mgorny, abidh, JDevlieghere, lldb-commits
Tags: #c_modules_in_lldb, #lldb
Differential Revision: https://reviews.llvm.org/D67760
llvm-svn: 372716
|
|
|
|
|
|
|
|
| |
The log channels change depending on platform, so listing them breaks on
some platforms. Let's just check that the 'lldb' and 'dwarf' channels are
there which are independent of platform.
llvm-svn: 372701
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since these defines were added in LLVM SVN r189364 in 2013,
mingw-w64 got defines for S_I?GRP, S_IRWXG, S_I?OTH and S_IRWXO
in 2015.
Also change the existing defined(_MSC_VER) into ifndef S_IRUSR, for
consistency.
Differential Revision: https://reviews.llvm.org/D67910
llvm-svn: 372700
|
|
|
|
|
|
|
|
|
|
| |
While debugging on those architectures might not be supported yet,
the generic code should still be buildable. This file accesses x86
specific fields in the CONTEXT struct.
Differential Revision: https://reviews.llvm.org/D67911
llvm-svn: 372699
|
|
|
|
|
|
|
| |
I refactored this code in 372691 and it seems I didn't fully
replicate the original log output, so that test was failing.
llvm-svn: 372696
|
|
|
|
|
|
|
|
|
|
|
| |
We currently have two lists in the CompletionRequest that we
inherited from the old API: The complete list of arguments ignoring
where the user requested completion and the list of arguments that
stops at the cursor. Having two lists of arguments is confusing
and can lead to subtle errors, so let's remove the complete list
until we actually need it.
llvm-svn: 372692
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67903
llvm-svn: 372691
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The ClangModulesDeclVendor is currently interpreting all injected `@import` statements in our expression
wrapper as modules that the user has explicitly requested to be persistently loaded. As we inject
`@import` statements with our std module prototype, the ClangModulesDeclVendor will start compiling
and loading unrelated C++ modules because it thinks the user has requested that it should load them. As
the ClangModulesDeclVendor is lacking the setup to compile these modules (e.g. it lacks the include paths),
it will then actually just fail to compile them and cause the whole expression evaluation to fail. This causes
these tests to fail on systems that enable the ClangModulesDeclVendor (such as macOS).
This patch fixes this by preventing the ClangModulesDeclVendor from interpreting `@import` statements
in the wrapper source code. This is done by check if the import happens in the fake source file containing
our wrapper code (which implies it was generated by LLDB).
This patch doesn't reenable the tests as there is more work needed to get the tests running on macOS (D67760)
Reviewers: aprantl, shafik, jingham
Subscribers: lldb-commits
Tags: #c_modules_in_lldb, #lldb
Differential Revision: https://reviews.llvm.org/D61565
llvm-svn: 372690
|
|
|
|
|
|
| |
Clang now emits the correct C++ language version in DWARF.
llvm-svn: 372677
|
|
|
|
|
|
|
|
|
|
| |
This patch extends the Makefile.rules to build NeXT-style frameworks. It
also fixes a bug in the clean logic that would accidentally delete the
.mm source file instead of the .o object file.
Thanks a lot to Adrian who was instrumental is getting this to work!
llvm-svn: 372669
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D67913
llvm-svn: 372658
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D67912
llvm-svn: 372657
|
|
|
|
|
|
|
|
|
|
|
| |
That change didn't contain any explanation for this bit. There shouldn't
be any need for a check for MinGW ifdefs here, as long as the include
uses lowercase windows.h (as is used consistently elsewhere in
the llvm projects).
Differential Revision: https://reviews.llvm.org/D67894
llvm-svn: 372656
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lvm_private::File::GetStream() can fail if m_options == 0
It's not clear from the header a File created with a descriptor will be
not be usable by many parts of LLDB unless SetOptions is also called,
but it is.
This is because those parts of LLDB rely on GetStream() to use the
file, and that in turn relies on calling fdopen on the descriptor. When
calling fdopen, GetStream relies on m_options to determine the access
mode. If m_options has never been set, GetStream() will fail.
This patch adds options as a required argument to File::SetDescriptor
and the corresponding constructor.
Patch by: Lawrence D'Anna
Differential revision: https://reviews.llvm.org/D67792
llvm-svn: 372652
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the file has m_stream, it may not have a m_descriptor.
GetWaitableHandle() should call GetDescriptor(), which will call
fileno(), so it will get waitable descriptor whenever one is available.
Patch by: Lawrence D'Anna
Differential revision: https://reviews.llvm.org/D67789
llvm-svn: 372644
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ABISysV ABI was refactored in r364216 to support the Windows ABI for
x86_64. In particular it changed ABISysV_x86_64::CreateInstance to
switch on the OS type. This breaks debugging MacABI apps as well as apps
in the simulator. This adds back the necessary cases.
We have a test on Github that exercises this code path and which I'd
like to upstream once the remaining MacABI parts become available in
clang.
Differential revision: https://reviews.llvm.org/D67869
llvm-svn: 372642
|
|
|
|
|
|
| |
The test is now passing, so remove the expected failure. No other tests associated with the bug are passing, though, so only remove expected failure from this one test
llvm-svn: 372634
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The indicated dead code may have performed some action; that action will never occur.
In lldb_private::LoadedModuleInfoList::LoadedModuleInfo::operator ==(lldb_private::LoadedModuleInfoList::LoadedModuleInfo const &): Code can never be reached because of a logical contradiction (CWE-561)
Coverity Scan: https://scan.coverity.com/projects/kwk-llvm-project?tab=overview
CID 221581
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67915
llvm-svn: 372608
|
|
|
|
|
|
|
|
|
|
|
| |
general
These ifdefs contain code that isn't specific to MSVC but useful for
any windows target, like MinGW.
Differential Revision: https://reviews.llvm.org/D67893
llvm-svn: 372592
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vsnprintf(NULL, 0, ...) works for measuring the needed string
size on all supported Windows variants; it's supported since
at least MSVC 2015 (and LLVM requires a newer version than that),
and works on both msvcrt.dll (since at least XP) and UCRT with MinGW.
The previous use of ifdefs was wrong as well, as __MINGW64__ only is
defined for 64 bit targets, and the define without trailing
underscores is never defined automatically (neither by clang nor
by gcc).
Differential Revision: https://reviews.llvm.org/D67861
llvm-svn: 372591
|
|
|
|
|
|
|
|
|
|
| |
This fixes build warnings in MinGW mode.
Also remove leftover if (log) {} around the log macro.
Differential Revision: https://reviews.llvm.org/D67896
llvm-svn: 372590
|
|
|
|
|
|
|
|
| |
The variable is unused on windows.
Differential Revision: https://reviews.llvm.org/D67895
llvm-svn: 372589
|
|
|
|
|
|
| |
This fixes build warnings with at least GCC.
llvm-svn: 372588
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The PECOFF object file plugin uses the dbghelp API, but doesn't
specify that it has to be linked in anywhere.
Current MSVC based builds have probably succeeded, as other parts
in LLDB have had a "#pragma comment(lib, "dbghelp.lib")", but there's
currently no such pragma in the PECOFF plugin.
The "#pragma comment(lib, ...)" approach doesn't work in MinGW mode
(unless the compiler is given the -fms-extensions option, and even
then, it's only supported by clang/lld, not by GCC/binutils), thus
add it to be linked via CMake. (The other parts of LLDB that use
dbghelp are within _MSC_VER ifdefs.)
Differential Revision: https://reviews.llvm.org/D67885
llvm-svn: 372587
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D67859
llvm-svn: 372586
|
|
|
|
| |
llvm-svn: 372574
|
|
|
|
| |
llvm-svn: 372572
|
|
|
|
| |
llvm-svn: 372569
|
|
|
|
|
|
|
| |
This was only an 'int' because to fit into the old API which is
gone by now.
llvm-svn: 372568
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fact that index==-1 means "no arguments" is not obvious and only
used in one place from what I can tell. Also fixes several warnings
about using the cursor index as if it was a size_t when comparing.
Not fully NFC as we now also correctly update the partial argument list
when injecting the fake empty argument in the CompletionRequest
constructor.
llvm-svn: 372566
|
|
|
|
| |
llvm-svn: 372561
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We should in general not allow external code to fiddle with the internals of
CompletionRequest, but until this is gone let's at least provide a utility
function that makes this less dangerous.
This also now correct updates the partially parsed argument list,
but it doesn't seem to be used by anything that is behind one of
the current shift/SetCursorIndex calls, so this doesn't seeem to
fix any currently used completion.
llvm-svn: 372556
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
context (partly reverts D61333)
Summary:
In D61333 we dropped some code from ClangASTSource that checks if imported declarations
ended up in the right DeclContext. While this code wasn't tested by the test suite (or better, it was hit
by the test suite but we didn't have any checks that were affected) and the code seems pointless
(as usually Decls should end up in the right DeclContext), it actually broke the data formatters in LLDB
and causes a bunch of obscure bugs where structs suddenly miss all their members. The first report we got about
this was that printing a std::map doesn't work anymore when simply doing "expr m" (m is the std::map).
This patch reverts D61333 partly and reintroduces the check in a more stricter way (we actually check now that
we *move* the Decl and it is in a single DeclContext). This should fix all the problems we currently have until
we figure out how to properly fix the underlying issues. I changed the order of some std::map formatter tests
which is currently the most reliable way to test this problem (it's a tricky setup, see description below).
Fixes rdar://55502701 and rdar://55129537
--------------------------------------
Some more explanation what is actually going on and what is going wrong:
The situation we have is that if we have a `std::map m` and do a `expr m`, we end up seeing an empty map
(even if `m` has elements). The reason for this is that our data formatter sees that std::pair<int, int> has no
members. However, `frame var m` works just fine (and fixes all following `expr m` calls).
The reason for why `expr` breaks std::map is that we actually copy the std::map nodes in two steps in the
three ASTContexts that are involved: The debug information ASTContext (D-AST), the expression ASTContext
we created for the current expression (E-AST) and the persistent ASTContext we use for our $variables (P-AST).
When doing `expr m` we do a minimal import of `std::map` from D-AST to E-AST just do the type checking/codegen.
This copies std::map itself and does a minimal.import of `std::pair<int, int>` (that is, we don't actually import
the `first` and `second` members as we don't need them for anything). After the expression is done, we take
the expression result and copy it from E-AST to P-AST. This imports the E-AST's `std::pair` into P-AST which still
has no `first` and `second` as they are still undeserialized. Once we are in P-AST, the data formatter tries to
inspect `std::map` (and also `std::pair` as that's what the elements are) and it asks for the `std::pair` members.
We see that `std::pair` has undeserialized members and go to the ExternalASTSource to ask for them. However,
P-ASTs ExternalASTSource points to D-AST (and not E-AST, which `std::pair` came from). It can't point to E-AST
as that is only temporary and already gone (and also doesn't actually contain all decls we have in P-AST).
So we go to D-AST to get the `std::pair` members. The ASTImporter is asked to copy over `std::pair` members
and first checks if `std::pair` is already in P-AST. However, it only finds the std::pair we got from E-AST, so it
can't use it's map of already imported declarations and does a comparison between the `std::pair` decls we have
Because the ASTImporter thinks they are different declarations, it creates a second `std::pair` and fills in the
members `first` and `second` into the second `std::pair`. However, the data formatter is looking at the first
`std::pair` which still has no members as they are in the other decl. Now we pretend we have no declarations
and just print an empty map as a fallback.
The hack we had before fixed this issue by moving `first` and `second` to the first declaration which makes
the formatters happy as they can now see the members in the DeclContext they are querying.
Obviously this is a temporary patch until we get a real fix but I'm not sure what's the best way to fix this.
Implementing that the ClassTemplateSpecializationDecl actually understands that the two std::pair's are the same
decl fixes the issue, but this doesn't fix the bug for all declarations. My preferred solution would be to
complete all declarations in E-AST before they get moved to P-AST (as we anyway have to do this from what I can
tell), but that might have unintended side-effects and not sure what's the best way to implement this.
Reviewers: friss, martong
Reviewed By: martong
Subscribers: aprantl, rnkovacs, christof, abidh, JDevlieghere, lldb-commits, shafik
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67803
llvm-svn: 372549
|
|
|
|
| |
llvm-svn: 372548
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This way it works better with MinGW.
Subscribers: mstorsjo, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67887
llvm-svn: 372493
|
|
|
|
|
|
|
|
|
|
| |
This silences warnings about comparison of integers between unsigned
long long (which is what the Windows SOCKET type is) and signed int
when building in MinGW mode.
Differential Revision: https://reviews.llvm.org/D67863
llvm-svn: 372486
|
|
|
|
|
|
|
|
|
|
|
| |
strings
SetErrorStringWithFormat only supports normal printf style format
strings.
Differential Revision: https://reviews.llvm.org/D67862
llvm-svn: 372485
|
|
|
|
|
|
|
|
| |
This fixes a warning when built with Clang in MinGW mode.
Differential Revision: https://reviews.llvm.org/D67860
llvm-svn: 372484
|
|
|
|
|
|
|
|
|
|
|
| |
addition to MSVC defines
This matches how it is done in all other similar ifdefs throughout
lldb.
Differential Revision: https://reviews.llvm.org/D67858
llvm-svn: 372483
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes build errors like these:
NativeRegisterContextWindows.h:22:33: error: extra qualification on member 'NativeRegisterContextWindows'
NativeRegisterContextWindows::NativeRegisterContextWindows(
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
Differential Revision: https://reviews.llvm.org/D67856
llvm-svn: 372482
|
|
|
|
|
|
|
|
|
|
|
|
| |
When swig fails, all the errors are squished onto one line with \n
quoting. It's very hard to read. This will print them out in a more
reasonable format.
Patch by: Lawrence D'Anna
Differential revision: https://reviews.llvm.org/D67790
llvm-svn: 372442
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dotest -f does not work on Python3.
The name types.UnboundMethodType was an alias for types.MethodType in
2.7, but it does not exist in python3. MethodType works in both.
Also the actual type returned from SomeClass.some_method in python3
will be types.Function, not MethodType.
Patch by: Lawrence D'Anna
Differential revision: https://reviews.llvm.org/D67791
llvm-svn: 372441
|
|
|
|
|
|
|
|
|
|
|
|
| |
If one reverts D66398 then the TestDataFormatterStdList does fail - as the C++
formatters are initialized in the opposite order. But the current state of
trunk does not mind the order for C++ formatters.
It is using now a single std::vector as suggested by Pavel Labath.
Differential Revision: https://reviews.llvm.org/D66654
llvm-svn: 372424
|
|
|
|
| |
llvm-svn: 372411
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The ASTImporterDelegate is currently responsible for both recording and also completing
types. This patch moves the actual completion and recording code outside the ASTImporterDelegate
to reduce the amount of responsibilities the ASTImporterDelegate has to fulfill.
As I anyway had to touch the code when moving I also documented and refactored most of it
(e.g. no more asserts that we call the deporting start/end function always as a pair).
Note that I had to make the ASTImporterDelegate and it's related functions public now so that
I can move out the functionality in another class (that doesn't need to be in the header).
Reviewers: shafik, aprantl, martong, a.sidorin
Reviewed By: martong
Subscribers: rnkovacs, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61478
llvm-svn: 372385
|
|
|
|
| |
llvm-svn: 372381
|