They are truncated when generating the version
numbers seen in the headers, so for example
lldb-100.1 would have #define LLDB_VERSION=100
llvm-svn: 154074
* s/nonstatic/non-static/ in the diagnostics, since the latter form outvoted
the former by 28-2 in our diagnostics.
* Fix the "use of member in static member function" diagnostic to correctly
detect this situation inside a block or lambda.
* Produce a more specific "invalid use of non-static member" diagnostic for
the case where a nested class member refers to a member of a
lexically-surrounding class.
llvm-svn: 154073
String literals (including unicode ones) can contain non-Unicode codepoints
if they were written using \x or similar. Write those out using \x, but be
careful that the following character can't be misinterpreted as part of the
\x escape sequence. Convert UTF-16 surrogate pairs back to codepoints before
rendering them.
llvm-svn: 154069
This diagnostic seems to be production ready, it's just an oversight that it
wasn't turned on by default.
The test changes are a bit of a mixed bag. Some tests that seemed like they
clearly didn't need to use this behavior have been modified not to use it.
Others that I couldn't be sure about, I added the necessary expected-warnings
to.
It's possible the diagnostic message could be improved to make it clearer that
this warning can be suppressed by using a value that won't lose precision when
converted to the target type (but can still be a floating point literal, such
as "bool b = 1.0;").
llvm-svn: 154068
correctly if the setter/getter were not present
in the debug information. The fixes are as follows:
- We not only look for the method by its full name,
but also look for automatically-generated methods
when searching for a selector in an Objective-C
interface. This is necessary to find accessors.
- Extract the getter and setter name from the
DW_TAG_APPLE_Property declaration in the DWARF
if they are present; generate them if not.
llvm-svn: 154067
Some high-level notes:
1) An explicit goal is to support building compiler-rt as a subproject
build, checked out into the projects/compiler-rt directory. There are
many other possible ways of building the code here, but this is
optimized for development on LLVM/Clang/compiler-rt, and incremental
trial and testing of the toolchain.
2) The current support is targeted at Linux. I would love to see this
generalized to other platforms, but for the sake of simplicity in
testing, I'm focusing here first.
Much of this patch was paired with Manuel, and I credit him with the
majority of the work here.
Some important caveats that I'll be working on in subsequent patches:
1) This uses the host compiler rather than using the just-built-clang.
2) Currently only x86 is supported.
3) Currently, none of the tests are built or run.
4) Uses CMake's builtin globbing which doesn't update correctly.
5) This is still turned off from LLVM's CMake build until these issues
are addressed
llvm-svn: 154060
I cannot build any part of this successfully on either Linux or Darwin,
and the replacement is worlds simpler by requiring that this be built as
a subproject of LLVM. If this breaks you for any reason, please let me
know, and let me know what your use case is.
llvm-svn: 154059
Found an issue where we might still have shared pointer references to lldb_private::Thread objects where the object itself is not valid and has been removed from the Process. When a thread is removed from a process, it will call Thread::DestroyThread() which well set a boolean member variable which is exposed now via:
bool
Thread::IsValid() const;
We then check the thread validity before handing out a shared pointer.
llvm-svn: 154048
uses Neon instructions for single-precision FP.
-mfpmath=neon is analogous to passing llc -mattr=+neonfp.
-mfpmath=[vfp|vfp2|vfp3|vfp4] is analogous to passing llc -mattr=-neonfp.
rdar://11108618
llvm-svn: 154046
A MOVCCr instruction can be commuted by inverting the condition. This
can help reduce register pressure and remove unnecessary copies in some
cases.
<rdar://problem/11182914>
llvm-svn: 154033
number + context) to the point where we initially start defining the
lambda, so that the linkage won't change when that information is made
available. Fixes the assertion in <rdar://problem/11182962>.
Plus, actually mangle the context of lambdas properly.
llvm-svn: 154029
Anna Zaks