| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Remove yet another spurious unexpected success.
Ack'ed by Jim Ingham.
Fixes PR25743.
llvm-svn: 320454
|
|
|
|
|
|
|
|
| |
After discussing this with Jim and Jason, I think my commit was
actually sweeping the issue under the carpet rather than fixing it.
I'll take a closer look between tonight and tomorrow.
llvm-svn: 320447
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some tests are failing on macOS when building with the in-tree
clang, and this is because they're conditional on the version released.
Apple releases using a different versioning number, but as these are
conditional on clang < 7, they fail for clang ToT (which is 6.0).
As a general solution, we actually need either a mapping between
Apple internal release version and public ones.
That said, I discussed this with Fred , and Apple Clang 6.0 seems
to be old enough that we can remove this altogether (which means I
can delay implementing the general purpose solution for a bit).
Differential Revision: https://reviews.llvm.org/D41101
llvm-svn: 320444
|
|
|
|
|
|
|
|
| |
Should hopefully bring the bots back.
<rdar://problem/35976115>
llvm-svn: 320422
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This mechanism was mostly redundant with the file-based .categories
mechanism, and it was interfering with it, as any test which implemented
a getCategories method would not inherit the filesystem categories.
This patch removes it. The existing categories are preserved either by
adding a .categories file, or using the @add_test_categories decorator.
Reviewers: jingham, clayborg, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D39515
llvm-svn: 317277
|
|
|
|
|
|
|
|
| |
running watchos. These tests cannot run on normal customer devices,
but I hope to some day have a public facing bot running against a
device.
llvm-svn: 314355
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
devices.
Normal customer devices won't be able to run these tests, we're hoping to get
a public facing bot set up at some point. Both devices pass the testsuite without
any errors or failures.
I have seen some instability with the armv7 test runs, I may submit additional patches
to address this. arm64 looks good.
I'll be watching the bots for the rest of today; if any problems are introduced by
this patch I'll revert it - if anyone sees a problem with their bot that I don't
see, please do the same. I know it's a rather large patch.
One change I had to make specifically for iOS devices was that debugserver can't
create files. There were several tests that launch the inferior process redirecting
its output to a file, then they retrieve the file. They were not trying to test
file redirection in these tests, so I rewrote those to write their output to a file
directly.
llvm-svn: 314132
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
arm64 iOS devices. Normal customer devices won't be able to run these devices, we're hoping to get a public facing bot set up at some point. Both devices pass the testsuite without any errors or failures."
This patch has been causing LLDB test failures on ObjC tests. A test log
may still be available here:
http://lab.llvm.org:8080/green/view/LLDB/job/lldb/1650/
This reverts commit r314038.
llvm-svn: 314122
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
devices.
Normal customer devices won't be able to run these devices, we're hoping to get
a public facing bot set up at some point. Both devices pass the testsuite without
any errors or failures.
I have seen some instability with the armv7 test runs, I may submit additional patches
to address this. arm64 looks good.
I'll be watching the bots for the rest of today; if any problems are introduced by
this patch I'll revert it - if anyone sees a problem with their bot that I don't
see, please do the same. I know it's a rather large patch.
One change I had to make specifically for iOS devices was that debugserver can't
create files. There were several tests that launch the inferior process redirecting
its output to a file, then they retrieve the file. They were not trying to test
file redirection in these tests, so I rewrote those to write their output to a file
directly.
llvm-svn: 314038
|
|
|
|
|
|
|
|
|
| |
changes going
in today and don't want the two changes to confuse the situation with the build bots.
I'll commit tomorrow once they're known good.
llvm-svn: 313934
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
devices.
Normal customer devices won't be able to run these devices, we're hoping to get
a public facing bot set up at some point.
There will be some smaller follow-on patches. The changes to tools/lldb-server are
verbose and I'm not thrilled with having to skip all of these tests manually.
There are a few places where I'm making the assumption that "armv7", "armv7k", "arm64"
means it's an ios device, and I need to review & clean these up with an OS check
as well. (Android will show up as "arm" and "aarch64" so by pure luck they shouldn't
cause problems, but it's not an assumption I want to rely on).
I'll be watching the bots for the rest of today; if any problems are introduced by
this patch I'll revert it - if anyone sees a problem with their bot that I don't
see, please do the same. I know it's a rather large patch.
One change I had to make specifically for iOS devices was that debugserver can't
create files. There were several tests that launch the inferior process redirecting
its output to a file, then they retrieve the file. They were not trying to test
file redirection in these tests, so I rewrote those to write their output to a file
directly.
llvm-svn: 313932
|
|
|
|
|
|
|
|
| |
Also un-xfailed a testcase that was affected by this. Thanks to Jason Molenda for the patch.
<rdar://problem/32827216>
llvm-svn: 306180
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
Objective-C classes.
Also added a test case, thanks to Greg Clayton.
<rdar://problem/18913551>
llvm-svn: 301993
|
|
|
|
|
|
|
|
|
|
| |
empty objective C types from the runtime.
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
|
|
|
|
|
|
|
| |
Fixes:
rdar://27792848
llvm-svn: 285032
|
|
|
|
|
|
| |
used platform.release
llvm-svn: 284674
|
|
|
|
| |
llvm-svn: 284446
|
|
|
|
| |
llvm-svn: 284296
|
|
|
|
| |
llvm-svn: 284183
|
|
|
|
| |
llvm-svn: 284182
|
|
|
|
| |
llvm-svn: 283959
|
|
|
|
| |
llvm-svn: 283957
|
|
|
|
| |
llvm-svn: 282869
|
|
|
|
| |
llvm-svn: 282794
|
|
|
|
| |
llvm-svn: 282787
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
|
|
|
|
|
|
|
| |
Tracked by:
rdar://27792848
llvm-svn: 278289
|
|
|
|
|
|
|
|
| |
Added test cases to exiting tests to cover the new functionality.
<rdar://problem/24311282>
llvm-svn: 275459
|
|
|
|
|
|
| |
<rdar://problem/17990991>
llvm-svn: 273718
|
|
|
|
|
|
|
|
| |
NSDictionary in the wrong order
Fixes rdar://26478641
llvm-svn: 273695
|
|
|
|
|
|
| |
<rdar://problem/22039804>
llvm-svn: 273632
|
|
|
|
|
|
| |
This reverts commit r272024 as it is not windows-compatible.
llvm-svn: 272062
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a lldbinline test's source file changed language, then the Makefile wasn't
updated. This was a problem if the Makefile was checked into the repository.
Now lldbinline.py always regenerates the Makefile and asserts if the
newly-generated version is not the same as the one already there. This ensures
that the repository will never be out of date without a buildbot failing.
http://reviews.llvm.org/D21032
llvm-svn: 272024
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change adds the capability of building test inferiors
with the -gmodules flag to enable module debug info support.
Windows is excluded per @zturner.
Reviewers: granata.enrico, aprantl, zturner, labath
Subscribers: zturner, labath, lldb-commits
Differential Revision: http://reviews.llvm.org/D19998
llvm-svn: 270848
|
|
|
|
|
|
|
| |
The test was failing on windows because the clean rule (which is executed even if the test is
skipped) returned an error there.
llvm-svn: 265140
|
|
|
|
|
|
| |
<rdar://problem/25447765>
llvm-svn: 264914
|
|
|
|
|
|
| |
All existing usages were ported over to the common decorators.
llvm-svn: 260290
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the following decorators:
* skipIfI386
* expectedFailureI386
* expectedFailurex86_64
* skipIfArch
* skipUnlessArch
* skipUnlessI386
And other related decorators. All code using those decorators
is updated to use expectedFailureAll and skipIf
llvm-svn: 260178
|
|
|
|
| |
llvm-svn: 259838
|
|
|
|
|
|
|
|
|
|
|
|
| |
This doesn't attempt to move every decorator. The reason for
this is that it requires touching every single test file to import
decorators.py. I would like to do this in a followup patch, but
in the interest of keeping the patches as bite-sized as possible,
I've only attempted to move the underlying common decorators first.
A few tests call these directly, so those tests are updated as part
of this patch.
llvm-svn: 259807
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is hitting an assert in clang when evaluating the
module load. I am seeing it locally on Xcode 7.3 public Beta 1
and on the llvm.org Green Dragon buildbot supposedly running
Xcode 7.0.
Tracked by:
https://llvm.org/bugs/show_bug.cgi?id=26267
llvm-svn: 258602
|
|
|
|
|
|
|
| |
assuming a ValueObject always has a process. So this is that fix
and the test case.
llvm-svn: 257242
|
|
|
|
|
|
|
| |
Tracked here:
https://llvm.org/bugs/show_bug.cgi?id=25743
llvm-svn: 254746
|
|
|
|
| |
llvm-svn: 254744
|
|
|
|
| |
llvm-svn: 252354
|