DavidSpickett wrote:
> So I'd prefer something global and possibly under user control, rather than
> doing it from formatter side. How does this sound to you?
Sure, I can always set it to on when printing registers so that would work for
me.
https://github.com/llvm/llvm-project/pull/69815
__
Endilll wrote:
@DavidSpickett There is `SBValue:SetFormat()`, which takes `lldb::Format`. We
can invent a new format, e.g. `eFormatEnumWithValue`. Not every enum flows
through my formatter, as I'm actively improving emitted debug info so that LLDB
does the right thing by default (`[[clang::pre
DavidSpickett wrote:
The existing code is
https://github.com/llvm/llvm-project/blob/865f54e501739f382d33866baebfd0f9aaad01bb/lldb/source/Core/DumpRegisterValue.cpp#L47.
Register contents is described as a packed struct with bitfields as members.
Now I am looking at making some of those enums s
DavidSpickett wrote:
Yeah sorry I dropped the context there, I copied over your change to
`lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp` into my changes to
get that output.
So what I meant to put across was that we are aiming for the same result.
https://github.com/llvm/llvm-proje
Endilll wrote:
> For this use case I'm setting options in lldb_private::DumpValueObjectOptions
> down in C++ but I'm not sure if those directly map to what a formatter would
> have access to.
@DavidSpickett What exactly do you set or unset there to get the output you're
showing? This approach
DavidSpickett wrote:
I would be interested in at least having a way to opt into this style, it would
be useful for registers for example here where I am experimenting with defining
`TCF` as an enum:
```
(lldb) register read mte_ctrl
mte_ctrl = 0x0007fffb
= (TAGS = 65535, TCF =
AaronBallman wrote:
> > > Is there a way to have Visual Studio change the display format of the
> > > enum values?
> >
> >
> > Sort of. You can specify you want to view values in hex and then you'll get
> > `EK_ParenAggInitMember (0x0015)` instead of `EK_ParenAggInitMember
> > (21)`, but
clayborg wrote:
> > Is there a way to have Visual Studio change the display format of the enum
> > values?
>
> Sort of. You can specify you want to view values in hex and then you'll get
> `EK_ParenAggInitMember (0x0015)` instead of `EK_ParenAggInitMember (21)`,
> but that all the more fo
AaronBallman wrote:
> Is there a way to have Visual Studio change the display format of the enum
> values?
Sort of. You can specify you want to view values in hex and then you'll get
`EK_ParenAggInitMember (0x0015)` instead of `EK_ParenAggInitMember (21)`,
but that all the more formatting
clayborg wrote:
Is there a way to have Visual Studio change the display format of the enum
values?
I currently like the way that enum values are displayed without any changes
where we try to show the enum value as an integer because I can change the
format if that is needed, or use the comma
AaronBallman wrote:
> What IDE are you using for the screenshot above?
Visual Studio
> The issue you might run into is that IDE might only be showing the value
> string and not the summary string. XCode and Visual Studio code will show the
> value if there is one _and_ the summary if there i
Endilll wrote:
@clayborg Thank you for extensive feedback! Can you clarify where do you want
me to put the changes?
---
You expected the following:
> v.SetFormat(lldb.eFormatDecimal)
v.GetValue()
`1(1)`
But my patch doesn't seem to alter the behavior of `eFormatDecimal`. The code
and LLDB out
clayborg wrote:
I agree with what Jim said as well. I would rather see the IDEs add the ability
to change the format for the values like Xcode can so that people can see their
values as needed. The summary here isn't a perfect option for this because if
you switch the format to `lldb::eFormatD
jimingham wrote:
This is a mostly orthogonal comment, but at some point, we really should switch
all the summaries that pretend to be the value of a variable to value providing
Synthetic Children.
Summaries are currently playing two fairly different roles, one some free-form
text that describ
clayborg wrote:
Another thing other IDEs do is show something like "{...}" as the value for a
struct/union/class. This is what Visual Studio used to do.
https://github.com/llvm/llvm-project/pull/69815
___
lldb-commits mailing list
lldb-commits@lists.l
clayborg wrote:
If we have a "Foo *", the value will show up as the pointer value _and_ the
summary for the Pointee (if `Foo` has a summary provider, it will show a
summary for it along with the pointer. If we have a "Foo", then there will be
no value for the struct/class instance and it will
clayborg wrote:
What IDE are you using for the screenshot above? The issue you might run into
is that IDE might only be showing the value string and not the summary string.
XCode and Visual Studio code will show the value if there is one _and_ the
summary if there is one. If there is no value
clayborg wrote:
> Making sure I'm following along properly. For context, this is the debug
> experience I'm most used to:
> 
>
> It sounds like you're saying we shouldn't change the
AaronBallman wrote:
Making sure I'm following along properly. For context, this is the debug
experience I'm most used to:
It sounds like you're saying we shouldn't change the enum formatter to d
clayborg wrote:
To clarify a bit: each value (SBValue in our public API, and ValueObject in our
private API) has the ability to supply a value string and a summary string. The
value string can depend on what the current format is set to. For an enum
value, the format defaults to `lldb::eFormat
https://github.com/clayborg requested changes to this pull request.
I am not sure about always showing the signed or unsigned value by default.
Enum values by default get displayed as the string value if we can find it. If
you want to see the value as signed or unsigned you can change the displ
AaronBallman wrote:
I'm not qualified to provide much of a review, but I'm in support of the
change, thank you for the patch!
https://github.com/llvm/llvm-project/pull/69815
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.
DavidSpickett wrote:
> I think we do:
I commented those out and got a bunch of test failures, so we're good on
coverage there.
https://github.com/llvm/llvm-project/pull/69815
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llv
@@ -23,9 +23,18 @@ def check_enum(self, suffix):
substrs=["Case1", "Case2", "Case3"],
)
# Test each case in the enum.
-self.expect_expr("var1_" + suffix, result_type=enum_name,
result_value="Case1")
-self.expect_expr("var2_" + suffix
@@ -23,9 +23,18 @@ def check_enum(self, suffix):
substrs=["Case1", "Case2", "Case3"],
)
# Test each case in the enum.
-self.expect_expr("var1_" + suffix, result_type=enum_name,
result_value="Case1")
-self.expect_expr("var2_" + suffix
https://github.com/Michael137 deleted
https://github.com/llvm/llvm-project/pull/69815
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -74,9 +74,13 @@ def test(self):
)
# Test an enum with fixed underlying type.
-self.expect_expr("A::scoped_char_enum_val", result_value="case2")
-self.expect_expr("A::scoped_ll_enum_val_neg", result_value="case0")
-self.expect_expr("A:
Endilll wrote:
> What happens with values that don't have a name, do we already have a
> fallback for that?
I think we do:
https://github.com/llvm/llvm-project/blob/2ad9fde41839879d8805d430c2e0857466d9c5d6/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp#L8563-L8571
Later there is a fa
DavidSpickett wrote:
I don't have the experience to know if enabling this globally makes sense, but
I do have a future use case for it.
At a some point I want to be able to describe register fields as enums, and
having the value as well as the name means you can match it up with the code
you'
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/69815
>From 886c627b8675886cfa09745c2441e3ab4aaadaea Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Sat, 21 Oct 2023 09:18:24 +0300
Subject: [PATCH 1/3] [lldb] Add number to enumerator dump
---
.../TypeSyste
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
4aae5387a874a55ee491f5dc23ce0506c5cdc678..886c627b8675886cfa09745c2441e3ab4aaadaea
lldb/
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 4aae5387a874a55ee491f5dc23ce0506c5cdc678
886c627b8675886cfa09745c2441e3ab4aaadaea --
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/69815
>From 886c627b8675886cfa09745c2441e3ab4aaadaea Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Sat, 21 Oct 2023 09:18:24 +0300
Subject: [PATCH 1/2] [lldb] Add number to enumerator dump
---
.../TypeSyste
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Vlad Serebrennikov (Endilll)
Changes
This patch adds the value to enumerator dump, e.g. `Enumerator` now dumped as
`Enumerator(0)`. There are not-so-uncommon cases when value of enumerator is no
less important than its name. One example ca
https://github.com/Endilll created
https://github.com/llvm/llvm-project/pull/69815
This patch adds the value to enumerator dump, e.g. `Enumerator` now dumped as
`Enumerator(0)`. There are not-so-uncommon cases when value of enumerator is no
less important than its name. One example can be foun
35 matches
Mail list logo
