Re: [lldb-dev] clang::VersionTuple

> On May 8, 2018, at 11:37 AM, Greg Clayton wrote: > > I was referring to the Swift and Apple internal branches. They tend to lock > down against older llvm and clang repositories so when we put changes in llvm > or clang that are required for LLDB, it makes merging a bit tougher in those >

Re: [lldb-dev] clang::VersionTuple

I was referring to the Swift and Apple internal branches. They tend to lock down against older llvm and clang repositories so when we put changes in llvm or clang that are required for LLDB, it makes merging a bit tougher in those cases. Again, I am not affected by this, just trying to watch out

Re: [lldb-dev] clang::VersionTuple

I'm good if Apple is good. > On May 8, 2018, at 11:31 AM, Frédéric Riss wrote: > > > >> On May 8, 2018, at 10:04 AM, Greg Clayton via lldb-dev >> mailto:lldb-dev@lists.llvm.org>> wrote: >> >> >> >>> On May 8, 2018, at 9:47 AM, Zachary Turner >> > wrote: >>> >>>

Re: [lldb-dev] clang::VersionTuple

> On May 8, 2018, at 10:04 AM, Greg Clayton via lldb-dev > wrote: > > > >> On May 8, 2018, at 9:47 AM, Zachary Turner > > wrote: >> >> We don’t want the lowest levels of lldb to depend on clang. If this is >> useful we should move it from clang to llvm and use ll

Re: [lldb-dev] clang::VersionTuple

Fred is probably the person who can answer this question On Tue, May 8, 2018 at 11:06 AM, Zachary Turner wrote: > +davide, +aprantl for the Apple perspective. > > > On Tue, May 8, 2018 at 10:04 AM Greg Clayton wrote: >> >> >> On May 8, 2018, at 9:47 AM, Zachary Turner wrote: >> >> We don’t wa

Re: [lldb-dev] clang::VersionTuple

+davide, +aprantl for the Apple perspective. On Tue, May 8, 2018 at 10:04 AM Greg Clayton wrote: > > On May 8, 2018, at 9:47 AM, Zachary Turner wrote: > > We don’t want the lowest levels of lldb to depend on clang. If this is > useful we should move it from clang to llvm and use llvm::VersionTu

Re: [lldb-dev] clang::VersionTuple

> On May 8, 2018, at 9:47 AM, Zachary Turner wrote: > > We don’t want the lowest levels of lldb to depend on clang. If this is useful > we should move it from clang to llvm and use llvm::VersionTuple I agree, though this move will cause merging issues for many that have repositories that lin

Re: [lldb-dev] clang::VersionTuple

We don’t want the lowest levels of lldb to depend on clang. If this is useful we should move it from clang to llvm and use llvm::VersionTuple On Tue, May 8, 2018 at 9:26 AM Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > No issues from me. > > > On May 8, 2018, at 9:11 AM, Pavel Laba

[lldb-dev] [Bug 37371] New: All tests in LinuxCoreTestCase fail on Windows

https://bugs.llvm.org/show_bug.cgi?id=37371 Bug ID: 37371 Summary: All tests in LinuxCoreTestCase fail on Windows Product: lldb Version: 6.0 Hardware: PC OS: Windows NT Status: NEW Severity: normal

Re: [lldb-dev] clang::VersionTuple

No issues from me. > On May 8, 2018, at 9:11 AM, Pavel Labath via lldb-dev > wrote: > > While moving Args around, I noticed that we have a bunch of > functions/classes that pass/store version numbers as a triplet of integers > (e.g. Platform::GetOSVersion). I got halfway into creating a wrapper

[lldb-dev] clang::VersionTuple

While moving Args around, I noticed that we have a bunch of functions/classes that pass/store version numbers as a triplet of integers (e.g. Platform::GetOSVersion). I got halfway into creating a wrapper class for that when I noticed clang::VersionTuple, which is pretty much what I wanted out of th

Re: [lldb-dev] What should SymbolFile::FindFunctions(..., eFunctionNameTypeFull, ...) do ?

On Fri, 4 May 2018 at 17:31, Greg Clayton wrote: > > On May 4, 2018, at 4:58 AM, Pavel Labath wrote: > > Is it really OK? If our indexes will never contain the demangled names, > > then the IRExecutionUnit lookups using the demangled names will always > > fail. (Right now they will only succeed f