https://github.com/AaronBallman commented:
The changes seem reasonable to me, but there are test failures in
`llvm/utils/lit/tests` that could perhaps be related to your changes.
I think .natvis files should be CRLF (those are used with Visual Studio for
debug visualizers).
dwblaikie wrote:
> For those files in the repository that do need CRLF endings, I've adopted a
> policy of eol=crlf which means that git will store them in history with LF,
> but regardless of user config, they'll be checked out in tree with CRLF.
This ^ seems a bit problematic to me, though
https://github.com/clayborg requested changes to this pull request.
SymbolFileDWARF::ParseLineTable() does more work after using llvm to parse the
line table and we still need to measure this. So I believe that the current
timer was in the correct position. Parse time for DWARF means how long
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/86568
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1228,10 +1231,9 @@ bool SymbolFileDWARF::ParseLineTable(CompileUnit
_unit) {
if (offset == DW_INVALID_OFFSET)
return false;
- ElapsedTime elapsed(m_parse_time);
clayborg wrote:
We want this to stay in this function so it measures all of the work
https://github.com/ZequanWu created
https://github.com/llvm/llvm-project/pull/86568
`ParseLineTable` not only parses .debug_line but also constructs `LineTable`.
This moves `m_parse_time` into the the function body of `ParseLLVMLineTable` to
more accurately reflect parsing time on
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Zequan Wu (ZequanWu)
Changes
`ParseLineTable` not only parses .debug_line but also constructs `LineTable`.
This moves `m_parse_time` into the the function body of `ParseLLVMLineTable` to
more accurately reflect parsing time on
@@ -1228,10 +1231,9 @@ bool SymbolFileDWARF::ParseLineTable(CompileUnit
_unit) {
if (offset == DW_INVALID_OFFSET)
return false;
- ElapsedTime elapsed(m_parse_time);
ZequanWu wrote:
My understanding is m_parse_time is the time spent only on parsing
fmayer wrote:
> . The point of this patch is not to lambast developers or interfere with
> their local setups; it's to get the line-ending issues out of the way for
> good so they can focus on what they do best.
Fair enough. I don't think it will fully make them go away for good, as you
ldrumm wrote:
> I don't have a strong opinion, but fundamentally I would prefer if the source
> control system stored exactly the files I have in my checkout, not mess with
> them in any way. I understand there are practical concerns, but a linter for
> unexpected CRLF would maybe be an
fmayer wrote:
> That wish is fine until you start working with others.
Do we actually have that little faith in developers that we think they will
check in a 50k line diff?
https://github.com/llvm/llvm-project/pull/86318
___
lldb-commits mailing
ldrumm wrote:
> > That wish is fine until you start working with others.
>
> Do we actually have that little faith in developers that we think they will
> check in a 50k line diff?
depending on their diff settings, or the web interface they use, it may not
show until they actually look at a
@@ -1228,10 +1231,9 @@ bool SymbolFileDWARF::ParseLineTable(CompileUnit
_unit) {
if (offset == DW_INVALID_OFFSET)
return false;
- ElapsedTime elapsed(m_parse_time);
clayborg wrote:
We want all of the time in LLDB to parse and prepare the data, not
github-actions[bot] wrote:
:white_check_mark: With the latest revision this PR passed the C/C++ code
formatter.
https://github.com/llvm/llvm-project/pull/86568
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
github-actions[bot] wrote:
:white_check_mark: With the latest revision this PR passed the Python code
formatter.
https://github.com/llvm/llvm-project/pull/86568
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
fmayer wrote:
I don't have a strong opinion, but fundamentally I would prefer if the source
control system stored exactly the files I have in my checkout, not mess with
them in any way. I understand there are practical concerns, but a linter for
unexpected CRLF would maybe be an option?
llvm-beanz wrote:
Philosophically I agree with this change, but I think some subprojects may need
to adopt specific policies about how they handle files that are expected to be
specific line endings. Specifically, Clang needs testing that verifies correct
behavior on both CRLF and LF files in
ldrumm wrote:
On Mon Mar 25, 2024 at 1:48 PM GMT, Tobias Hieta wrote:
> > I think .natvis files should be CRLF (those are used with Visual Studio for
> > debug visualizers).
>
> Agreed, Visual Studio should handle this correctly, but who knows
> 路
>
Thanks. I'll add a rule and update
kevinfrei wrote:
> New tests apparently are failing on Arm/AArch64 Linux.
The failure indicates that the failing tests' build don't include a UUID, which
*should* be generated by the changes to Makefile.rules. Any idea how I ought to
proceed with reproducing a build on a system that I have
tru wrote:
> I think .natvis files should be CRLF (those are used with Visual Studio for
> debug visualizers).
Agreed, Visual Studio should handle this correctly, but who knows 路
https://github.com/llvm/llvm-project/pull/86318
___
lldb-commits
Michael137 wrote:
> > > What happens if you have colors disabled in your terminal? Does this do
> > > nothing? Or does it start inserting ANSI escape codes in plain text?
> >
> >
> > Yea good question, was about to try this out. It does whatever clang's
> > `ast-dump` would do if colors
jimingham wrote:
You can't get from a TypeSystem to a Target directly, because TypeSystem's live
in Modules and Modules live outside any particular target in the global module
cache. Maybe you need to pass this in to the call to dump the functions. The
command-line will always have a
ldrumm wrote:
> Should we come up with an expected filename format that we can use with
> gitattributes and rename the existing files rather than just listing each
> file that has special needs by itself?
Either way, the author has to do or know *something*. I'm not a fan of "magic"
like
Author: Jonas Devlieghere
Date: 2024-03-25T15:25:58-07:00
New Revision: 4dcb1db44f9dbfa09c220703a1b097f51d20a2a5
URL:
https://github.com/llvm/llvm-project/commit/4dcb1db44f9dbfa09c220703a1b097f51d20a2a5
DIFF:
https://github.com/jimingham created
https://github.com/llvm/llvm-project/pull/86593
This has been available for years now, so it should be safe to always use it.
>From 1886d705aee10cf608b4c452bea6ea3e47c4b25d Mon Sep 17 00:00:00 2001
From: Jim Ingham
Date: Mon, 25 Mar 2024 15:31:50 -0700
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: None (jimingham)
Changes
This has been available for years now, so it should be safe to always use it.
---
Full diff: https://github.com/llvm/llvm-project/pull/86593.diff
1 Files Affected:
- (modified) lldb/docs/use/python-reference.rst
https://github.com/bulbazord edited
https://github.com/llvm/llvm-project/pull/86593
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/bulbazord approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/86593
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -491,34 +491,42 @@ which will work like all the natively defined lldb
commands. This provides a
very flexible and easy way to extend LLDB to meet your debugging requirements.
To write a python function that implements a new LLDB command define the
-function to take four
@@ -491,34 +491,42 @@ which will work like all the natively defined lldb
commands. This provides a
very flexible and easy way to extend LLDB to meet your debugging requirements.
To write a python function that implements a new LLDB command define the
-function to take four
llvm-beanz wrote:
> This ^ seems a bit problematic to me, though (where the contents of the repo
> isn't representative of the bits we want - but perhaps it's schrodinger's
> line endings & it doesn't matter if it's always checked out as crlf - though
> if we one day converted to another
https://github.com/JDevlieghere approved this pull request.
Ship it!
https://github.com/llvm/llvm-project/pull/86359
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/86359
>From 47bf1259289986cdc0df706aa40a18e58e94eee5 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Fri, 22 Mar 2024 16:31:07 -0700
Subject: [PATCH] [lldb] [ObjectFileMachO] LLVM_COV is not mapped into
Author: jimingham
Date: 2024-03-25T15:17:23-07:00
New Revision: 2c76e88e9eb284d17cf409851fb01f1d583bb22a
URL:
https://github.com/llvm/llvm-project/commit/2c76e88e9eb284d17cf409851fb01f1d583bb22a
DIFF:
https://github.com/llvm/llvm-project/commit/2c76e88e9eb284d17cf409851fb01f1d583bb22a.diff
https://github.com/jimingham closed
https://github.com/llvm/llvm-project/pull/85492
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Jason Molenda
Date: 2024-03-25T15:00:36-07:00
New Revision: 765d4c402fe2ff614a15a762bb7cefe7289663b4
URL:
https://github.com/llvm/llvm-project/commit/765d4c402fe2ff614a15a762bb7cefe7289663b4
DIFF:
https://github.com/llvm/llvm-project/commit/765d4c402fe2ff614a15a762bb7cefe7289663b4.diff
https://github.com/jasonmolenda closed
https://github.com/llvm/llvm-project/pull/86359
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
llvm-beanz wrote:
> I'm a bit confused. Are you saying that as I've expressed it, `autocrlf=true`
> won't work correctly? I _think_ you're saying you're in favour of this patch
> _in principal_, but I need to fix the mixed line endings case?
Sorry for being unclear. I meant to express that
Author: Jonas Devlieghere
Date: 2024-03-25T14:50:58-07:00
New Revision: 930f64689c1fb487714c3836ffa43e49e46aa488
URL:
https://github.com/llvm/llvm-project/commit/930f64689c1fb487714c3836ffa43e49e46aa488
DIFF:
https://github.com/JDevlieghere closed
https://github.com/llvm/llvm-project/pull/84854
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/chelcassanova approved this pull request.
https://github.com/llvm/llvm-project/pull/86593
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: jimingham
Date: 2024-03-25T16:06:51-07:00
New Revision: b6dfaf4c291ee186481f6c1dcab03874d931c307
URL:
https://github.com/llvm/llvm-project/commit/b6dfaf4c291ee186481f6c1dcab03874d931c307
DIFF:
https://github.com/llvm/llvm-project/commit/b6dfaf4c291ee186481f6c1dcab03874d931c307.diff
https://github.com/jimingham updated
https://github.com/llvm/llvm-project/pull/86593
>From 1886d705aee10cf608b4c452bea6ea3e47c4b25d Mon Sep 17 00:00:00 2001
From: Jim Ingham
Date: Mon, 25 Mar 2024 15:31:50 -0700
Subject: [PATCH 1/2] Make the correct (5 argument) form of the command
definition
https://github.com/jimingham closed
https://github.com/llvm/llvm-project/pull/86593
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
llvm-beanz wrote:
> I am not saying this isn't a problem at all, but how often has anyone done a
> one line change and caused a 50k diff, and submitted it without noticing?
Way more often than you would hope. I don't have numbers but if you search
through the git history for `crlf` or
jasonmolenda wrote:
I've seen this ubsan error every time I run the testsuite for years, i just
finally sat down and figured out what was going on.
https://github.com/llvm/llvm-project/pull/86605
___
lldb-commits mailing list
https://github.com/jeffreytan81 created
https://github.com/llvm/llvm-project/pull/86623
None
>From 6cccde22723157260e7c0b19bf8372aae8d1afaa Mon Sep 17 00:00:00 2001
From: jeffreytan81
Date: Wed, 6 Mar 2024 12:07:03 -0800
Subject: [PATCH 1/3] Fix strcmp build error on buildbot
---
github-actions[bot] wrote:
:warning: Python code formatter, darker found issues in your code. :warning:
You can test this locally with the following command:
``bash
darker --check --diff -r
93f9fb2c825dba48db64d5f726b54bcbd4766009...b2dfdb546808c495779e5781c6619fcadb752b00
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 93f9fb2c825dba48db64d5f726b54bcbd4766009
b2dfdb546808c495779e5781c6619fcadb752b00 --
49 matches
Mail list logo
