https://llvm.org/bugs/show_bug.cgi?id=17384
ravithejaw...@gmail.com changed:
What|Removed |Added
CC||ravithejaw...@gmail.com
Assi
Nice! Out of curiosity, do all the unittests pass? (I expect they do, as
they do everywhere else, just wondering)
On Sun, Oct 25, 2015 at 2:57 PM Todd Fiala via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> This should be fixed with:
> $ svn commit
> unittests/Editline/CMakeLists.txt
> Transmitt
git clang-format should do it. There are two things it doesn't handle:
1) It puts constructor initializer list separators (comma and colon) at the
beginning of each line instead of at the end of each line.
2) It doesn't put return type on a separate line for declarations (but it
does for definiti
I am surprised that this doesn't work as we make an effort to pass the current
environment down to any processes that you spawn by default (at least on MacOSX
we do), but the solution is easy: use the --environment variable with the
"process launch" command:
(lldb) process launch --environment
I spoke with Sean Callanan on this and he suggests you submit a patch where we
use "_$" to Phabricator and then we can OK this and get this into LLDB for
good. Thanks for looking into this.
Greg
> On Oct 25, 2015, at 10:24 PM, Bhushan Attarde
> wrote:
>
> Hi Greg,
>
> I tried using "_$" and
Awesome, thanks Zachary!
On Mon, Oct 26, 2015 at 9:38 AM, Zachary Turner wrote:
> git clang-format should do it. There are two things it doesn't handle:
>
> 1) It puts constructor initializer list separators (comma and colon) at
> the beginning of each line instead of at the end of each line.
>
Yes, they do.
On Mon, Oct 26, 2015 at 9:34 AM, Zachary Turner wrote:
> Nice! Out of curiosity, do all the unittests pass? (I expect they do, as
> they do everywhere else, just wondering)
>
> On Sun, Oct 25, 2015 at 2:57 PM Todd Fiala via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> This s
Okay, I'm stuck again. Let's back up and see what's happening:
~/src$ git clone llvm/
~/src$ mkdir llvm-build/
~/src/llvm-build$ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug ../llvm
~/src/llvm-build$ ninja
Now, ~/src/llvm-build/lib/libLLVMCore.a contains DWARF information
that points to files ~/src/llv
So when LLDB parses the DW_AT_decl_file attributes, it uses the files from the
line table for the current compile unit. Each of those files is passed through
the module source remapping function:
bool
Module::RemapSourceFile (const char *path, std::string &new_path) const
{
Mutex::Locker loc
After speaking with Adrian Prantl over here we came up with a solution.
Currently we do this when uniquing types:
// Only try and unique the type if it has a name.
if (type_name_const_str &&
dwarf->GetUniqueDWARFASTTypeMap().Find (type_name_const_str,
Greg,
Greg Clayton wrote:
> Note that for C++ we get the fully qualified name and we pass in an empty
> Declaration() so they all will compare to the same thing. This would solve
> our current issue. We would also need to add the items to this map in the
> same way: for C++ get the fully quali
> On Oct 26, 2015, at 12:45 PM, Ramkumar Ramachandra wrote:
>
> Greg,
>
> Greg Clayton wrote:
>> Note that for C++ we get the fully qualified name and we pass in an empty
>> Declaration() so they all will compare to the same thing. This would solve
>> our current issue. We would also need to
12 matches
Mail list logo
