NSString is loaded from the DWARF, which doesn't have the concept of protocols.
When this is used with the NSMutableDictionary type from Objective-C modules,
this produces errors of the form
error: cannot initialize a parameter of type 'id<NSCopying> _Nonnull' with an rvalue of type 'NSString *'
We're aware of these problems and have an internal bug report filed
(<rdar://problem/32777981>)
llvm-svn: 305424
Clang does not accept regparm attribute on these platforms.
Fortunately, the default calling convention passes arguments
in registers any way
Subscribers: jaydeep, bhushan, lldb-commits, slthakur
llvm-svn: 305378
When parsing types originating in modules, it is possible to encounter AttributedTypes
(such as the type generated for NSString *_Nonnull). Some of LLDB's ClangASTContext
methods deal with them; others do not. In particular, one function that did not was
GetTypeInfo, causing TestObjCNewSyntax to fail.
This fixes that, treating AttributedType as essentially transparent and getting the
information for the modified type.
In addition, however, TestObjCNewSyntax is a monolithic test that verifies a bunch of
different things, all of which can break independently of one another. I broke it
apart into smaller tests so that we get more precise failures when something (like
this) breaks.
Differential Revision: https://reviews.llvm.org/D33812
llvm-svn: 304510
This works on SVN but is a bit fragile on the Swift branch.
I'm adding the test to both, so we have this path covered.
<rdar://problem/32372372>
llvm-svn: 304314
For remote targets we need to call registerSharedLibrariesWithTarget to
make sure they are installed alongside main executable. This also
required a small fixup in the the mentioned function as in this case
"One" was both a directory name and a library name template. I fixed it
to make sure it checks that the string refers to a file before it
assumed it was a full library path.
llvm-svn: 303248
When it resolves symbol-only variables, the expression parser
currently looks only in the global module list. It should prefer
the current module.
I've fixed that behavior by making it search the current module
first, and only search globally if it finds nothing. I've also
added a test case.
After review, I moved the core of the lookup algorithm into
SymbolContext for use by other code that needs it.
Thanks to Greg Clayton and Pavel Labath for their help.
Differential Revision: https://reviews.llvm.org/D33083
llvm-svn: 303223
ptr_refs exposed a problem in ClangASTContext's implementation: it
uses an accessor to downcast a QualType to an
ObjCObjectPointerType, but the accessor is not fully general.
getAs() is the safer way to go.
I've added a test case that uses ptr_refs in a way that would
crash before the fix.
<rdar://problem/31363513>
llvm-svn: 303110
Templates can end in parameter packs, like this
template <class T...> struct MyStruct
{ /*...*/ };
LLDB does not currently support these parameter packs;
it does not emit them into the template argument list
at all. This causes problems when you specialize, e.g.:
template <> struct MyStruct<int>
{ /*...*/ };
template <> struct MyStruct<int, int> : MyStruct<int>
{ /*...*/ };
LLDB generates two template specializations, each with
no template arguments, and then when they are imported
by the ASTImporter into a parser's AST context we get a
single specialization that inherits from itself,
causing Clang's record layout mechanism to smash its
stack.
This patch fixes the problem for classes and adds
tests. The tests for functions fail because Clang's
ASTImporter can't import them at the moment, so I've
xfailed that test.
Differential Revision: https://reviews.llvm.org/D33025
llvm-svn: 302833
gnuwin32 rm does not like wildcards that match nothing even if we
specify -f (probably because the wildcard expansion happens in-process
there). We could use make $(wildcard) here, but it seems safer to
explicitly list the files here, just like the normal Makefile.rules
does.
llvm-svn: 302013
Loading a shared library can require a large amount of work; rather than do that serially for each library,
this patch will allow parallelization of the symbols and debug info name indexes.
From scott.smith@purestorage.comhttps://reviews.llvm.org/D32598
llvm-svn: 301609
Many times a user wants to access a type when there's a variable of
the same name, or a variable when there's a type of the same name.
Depending on the precise context, currently the expression parser
can fail to resolve one or the other.
This is because ClangExpressionDeclMap has logic to limit the
amount of information it searches, and that logic sometimes cuts
down the search prematurely. This patch removes some of those early
exits.
In that sense, this patch trades performance (early exit is faster)
for correctness.
I've also included two new test cases showing examples of this
behavior – as well as modifying an existing test case that gets it
wrong.
llvm-svn: 301273
LLDB uses clang::DeclContexts for lookups, and variables get put into
the DeclContext for their abstract origin. (The abstract origin is a
DWARF pointer that indicates the unique definition of inlined code.)
When the expression parser is looking for variables, it locates the
DeclContext for the current context. This needs to be done carefully,
though, e.g.:
__attribute__ ((always_inline)) void f(int a) {
{
int b = a * 2;
}
}
void g() {
f(3);
}
Here, if we're stopped in the inlined copy of f, we have to find the
DeclContext corresponding to the definition of f – its abstract
origin. Clang doesn't allow multiple functions with the same name and
arguments to exist. It also means that any variables we see must be
placed in the appropriate DeclContext.
[Bug 1]: When stopped in an inline block, the function
GetDeclContextDIEContainingDIE for that block doesn't properly
construct a DeclContext for the abstract origin for inlined
subroutines. That means we get duplicated function DeclContexts, but
function arguments only get put in the abstract origin's DeclContext,
and as a result when we try to look for them in nested contexts they
aren't found.
[Bug 2]: When stopped in an inline block, the DWARF (for space
reasons) doesn't explicitly point to the abstract origin for that
block. This means that the function GetClangDeclContextForDIE returns
a different DeclContext for each place the block is inlined. However,
any variables defined in the block have abstract origins, so they
will only get placed in the DeclContext for their abstract origin.
In this fix, I've introduced a test covering both of these issues,
and fixed them.
Bug 1 could be resolved simply by making sure we look up the abstract
origin for inlined functions when looking up their DeclContexts on
behalf of nested blocks.
For Bug 2, I've implemented an algorithm that makes the DeclContext
for a block be the containing DeclContext for the closest entity we
would find during lookup that has an abstract origin pointer. That
means that in the following situation:
{ // block 1
int a;
{ // block 2
int b;
}
}
if we looked up the DeclContext for block 2, we'd find the block
containing the abstract origin of b, and lookup would proceed
correctly because we'd see b and a. However, in the situation
{ // block 1
int a;
{ // block 2
}
}
since there isn't anything to look up in block 2, we can't determine
its abstract origin (and there is no such pointer in the DWARF for
blocks). However, we can walk up the parent chain and find a, and its
abstract origin lives in the abstract origin of block 1. So we simply
say that the DeclContext for block 2 is the same as the DeclContext
for block 1, which contains a. Lookups will return the same results.
Thanks to Jim Ingham for review and suggestions.
Differential revision: https://reviews.llvm.org/D32375
llvm-svn: 301263
The test fails because an older clang did not emit the required debug
info (I am not sure when this got added, but clang-3.7 certainly did not
work yet). The actual platform has nothing to do with this.
llvm-svn: 300834
Clang rejects __attribute__((regparm)) when targetting arm. The default
calling convention passes arguments in registers anyway, so we can just
remove them in this case.
llvm-svn: 300670
This fixes a bug introduced by r291559. The Module's FindType was
passing the original name not the basename in the case where it didn't
find any separators. I also added a testcase for this.
<rdar://problem/31159173>
llvm-svn: 298331
We are going to turn off buffer overflow introduced by gcc by turning off
FORTIFY_SOURCE.
Differential revision: https://reviews.llvm.org/D28666
llvm-svn: 291949
We don't parse ObjC v1 types from the runtime metadata like we do for ObjC v2, but doing so by creating empty types was ruining the i386 v1 debugging experience.
<rdar://problem/24093343>
llvm-svn: 289233
We have a longstanding issue where the expression parser does not handle wide CFStrings (e.g., @"凸凹") correctly, producing the useless error message
Internal error [IRForTarget]: An Objective-C constant string's string initializer is not an array
error: warning: expression result unused
error: The expression could not be prepared to run in the target
This is just a side effect of the fact that we don't handle wide string constants when converting these to CFStringCreateWithBytes. That function takes the string's encoding as an argument, so I made it work and added a testcase.
https://reviews.llvm.org/D27291
<rdar://problem/13190557>
llvm-svn: 288386
Fails with all versions of arm/aarch64 gcc available on ubuntu 16.04/14.04.
Passes with Linaro GCC version >= 4.8 but fails with >= 5.0. But There are other regressions when we use Linaro GCC.
llvm-svn: 286574
The debug info emitted by clang for static variables improved by
rL286302 and it exposed an incorrect test expactation because now LLDB
able to displays more data 9thanks to better debug info) then before.
llvm-svn: 286360
Sean Callanan