- FormatCategories now are directly mapped by ConstString objects instead of going through
const char* -> ConstString -> const char*
- FormatCategory callback does not pass category name anymore. This is not necessary because
FormatCategory objects themselves hold their name as a member variable
llvm-svn: 138254
If you have a Python module foo, in order to use its contained objects in LLDB you do not need to use
'from foo import *'. You can use 'import foo', and then refer to items in foo as 'foo.bar', and LLDB
will know how to resolve bar as a member of foo.
Accordingly, GNU libstdc++ formatters have been moved from the global namespace to gnu_libstdcpp and a few
test cases are also updated to reflect the new convention. Python docs suggest using a plain 'import' en lieu of
'from-import'.
llvm-svn: 138244
const int &x = x;
This crashed by inifinetly recursing within the lvalue evaluation
routine. I've added a (somewhat) braindead way of preventing this
recursion. If folks have better suggestions for how to avoid it I'm all
ears.
That said, we have some work to do. This doesn't trigger a single
warning for uninitialized, self-initialized or otherwise completely
wrong code. In some senses, the crash was almost better.
llvm-svn: 138239
functionality into DEFINE_TRANSPARENT_OPERAND_ACCESSORS. A side-effect
of this is that the operand accessors for Constants will tolerate NULL
operands, fixing PR10663.
llvm-svn: 138230
plug-ins are add on plug-ins for the lldb_private::Process class that can add
thread contexts that are read from memory. It is common in kernels to have
a lot of threads that are not currently executing on any cores (JTAG debugging
also follows this sort of thing) and are context switched out whose state is
stored in memory data structures. Clients can now subclass the OperatingSystem
plug-ins and then make sure their Create functions correcltly only enable
themselves when the right binary/target triple are being debugged. The
operating system plug-ins get a chance to attach themselves to processes just
after launching or attaching and are given a lldb_private::Process object
pointer which can be inspected to see if the main executable, target triple,
or any shared libraries match a case where the OS plug-in should be used.
Currently the OS plug-ins can create new threads, define the register contexts
for these threads (which can all be different if desired), and populate and
manage the thread info (stop reason, registers in the register context) as
the debug session goes on.
llvm-svn: 138228
Currently getMacroArgExpandedLocation is very inefficient and for the case
of a location pointing at the main file it will end up checking almost all of
the SLocEntries. Make it faster:
-Use a map of macro argument chunks to their expanded source location. The map
is for a single source file, it's stored in the file's ContentCache and lazily
computed, like the source lines cache.
-In SLocEntry's FileInfo add an 'unsigned NumCreatedFIDs' field that keeps track
of the number of FileIDs (files and macros) that were created during preprocessing
of that particular file SLocEntry. This is useful when computing the macro argument
map in skipping included files while scanning for macro arg FileIDs that lexed from
a specific source file. Due to padding, the new field does not increase the size
of SLocEntry.
llvm-svn: 138225
I am planning to eliminate the TempScopInfo pass. To simplify this I remove
some features that may later be added to the ScopInfo pass.
The interchange pass is currently strongly tested and furthermore ment to be
replaced by the general scheduling optimizer. Reductions itself can later
be added easily.
llvm-svn: 138219
Because of me not understanding the LLVM pass structure well, I did not find a
good way to allocate isl_ctx and to free it later without getting issues with
reference counting. I now found this place, such that we can free isl_ctx. This
patch also fixes the memory leaks that were ignored beforehand.
llvm-svn: 138204
like to avoid within the Clang test suite, it doesn't verify the output
at all so it only servers as a test that Clang doesn't crash, and
finally all it does is declare a function that returns a vector and call
it. Probably the biggest thing being tested here is Clang's parsing of
the vector template, and we have lots of good template parsing tests. We
don't need another in codegen.
llvm-svn: 138197
Bill Wendling