[lldb-dev] Problem formatting class types

[Zachary Turner via lldb-dev]

Hello,

I've got this code:

class Class {
  int x = 0;
  short y = 1;
  char z = 'z';
} C;

int main(int argc, char **argv) {
  __debugbreak();
  return 0;
}

and I run the following LLDB session:

lldb.exe -f foo.exe
(lldb) target create "foo.exe"
Current executable set to 'foo.exe' (x86_64).
(lldb) run
Process 24604 launched: 'foo.exe' (x86_64)
Process 24604 stopped
* thread #1, stop reason = Exception 0x8003 encountered at address
0x7ff70a0b1017
frame #0: 0x7ff70a0b1018 foo.exe`main(argc=-1123614720,
argv=0x7ff70a0b1000) at foo.cpp:19
   16
   17   int main(int argc, char **argv) {
   18 __debugbreak();
-> 19 return 0;
   20   }
(lldb) p C
(Class) $0 =
(lldb)

The issue is, of course, that it doesn't display the members of the class
C.  The type support in PDB is fine, so it's not that.  For example:

(lldb) type lookup Class
class Class {
int x;
short y;
char z;
}

And it can definitely find C in memory:

(lldb) p &C
(Class *) $1 = 0x7ff70a0b3000

Instead, the issue seems to be related to the value object formatter.  I
tried to track this down but this code is pretty complicated.  However,
there are two issues that I was able to discover:

1) It's using the objective C class formatter.  Obviously I'm not using
objective C, so that seems wrong right off the bat.  Specifically, the
"Synthetic children front end" is the ObjCClassSyntheticChildrenFrontEnd.

2) Because of #1, when it calls CalculateNumChildren() in Cocoa.cpp, it
returns 0.  I would expect it to be calling some function somewhere that
returns 3, because there are 3 members of the class.

What's strange is that I don't see anything in the CPlusPlusLanguage plugin
that provides a SyntheticChildrenFrontEnd that examines the CxxRecordDecl
and looks for children, so I don't know how this is supposed to work
anywhere.  But I know it must work somewhere, so I assume I'm just missing
something and I need to find out the right place to hook A up to B and
things will just work.

Any pointers on what the expected code path that this should be taking is,
so I can try to figure out where I might be going off path?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Problem formatting class types

[Zachary Turner via lldb-dev]

Note that I also tried this with a a linux / DWARF executable and had the
same result.

On Fri, Oct 26, 2018 at 3:21 AM Zachary Turner  wrote:

> Hello,
>
> I've got this code:
>
> class Class {
>   int x = 0;
>   short y = 1;
>   char z = 'z';
> } C;
>
> int main(int argc, char **argv) {
>   __debugbreak();
>   return 0;
> }
>
> and I run the following LLDB session:
>
> lldb.exe -f foo.exe
> (lldb) target create "foo.exe"
> Current executable set to 'foo.exe' (x86_64).
> (lldb) run
> Process 24604 launched: 'foo.exe' (x86_64)
> Process 24604 stopped
> * thread #1, stop reason = Exception 0x8003 encountered at address
> 0x7ff70a0b1017
> frame #0: 0x7ff70a0b1018 foo.exe`main(argc=-1123614720,
> argv=0x7ff70a0b1000) at foo.cpp:19
>16
>17   int main(int argc, char **argv) {
>18 __debugbreak();
> -> 19 return 0;
>20   }
> (lldb) p C
> (Class) $0 =
> (lldb)
>
> The issue is, of course, that it doesn't display the members of the class
> C.  The type support in PDB is fine, so it's not that.  For example:
>
> (lldb) type lookup Class
> class Class {
> int x;
> short y;
> char z;
> }
>
> And it can definitely find C in memory:
>
> (lldb) p &C
> (Class *) $1 = 0x7ff70a0b3000
>
> Instead, the issue seems to be related to the value object formatter.  I
> tried to track this down but this code is pretty complicated.  However,
> there are two issues that I was able to discover:
>
> 1) It's using the objective C class formatter.  Obviously I'm not using
> objective C, so that seems wrong right off the bat.  Specifically, the
> "Synthetic children front end" is the ObjCClassSyntheticChildrenFrontEnd.
>
> 2) Because of #1, when it calls CalculateNumChildren() in Cocoa.cpp, it
> returns 0.  I would expect it to be calling some function somewhere that
> returns 3, because there are 3 members of the class.
>
> What's strange is that I don't see anything in the CPlusPlusLanguage
> plugin that provides a SyntheticChildrenFrontEnd that examines the
> CxxRecordDecl and looks for children, so I don't know how this is supposed
> to work anywhere.  But I know it must work somewhere, so I assume I'm just
> missing something and I need to find out the right place to hook A up to B
> and things will just work.
>
> Any pointers on what the expected code path that this should be taking is,
> so I can try to figure out where I might be going off path?
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [RFC] LLVM bug lifecycle BoF - triaging

[Kristof Beyls via lldb-dev]

On 26 Oct 2018, at 04:26, Richard Smith 
mailto:rich...@metafoo.co.uk>> wrote:

On Thu, 25 Oct 2018 at 05:10, Kristof Beyls via cfe-dev 
mailto:cfe-...@lists.llvm.org>> wrote:
On 5 Oct 2018, at 07:04, Dean Michael Berris 
mailto:dean.ber...@gmail.com>> wrote:

Thank you for starting this conversation! I look forward to the results of the 
BoF discussion summarised as well.

Dean, all,

There was a lively discussion at the BoF; we’ve tried to take notes at 
https://etherpad.net/p/LLVMBugLifeCycleBoF but probably have failed to capture 
all the points. The slides used to kick start the discussion can be found at 
https://docs.google.com/presentation/d/1ERB9IQAjSwaNpEnlbchQzd_V9IQlLOojgo9J0_NXvYA/edit

Both at the BoF and in the mail thread, there have been many suggestions for 
improvements. So many that if we’d want to introduce all of them at once, we’d 
probably get stuck and not introduce any. To try and make progress on the ones 
I myself feel are most useful, I’ve volunteered for 2 actions:

1. Write up a proposal for documentation on what to do during bug 
triaging/closing/etc. I’ve just done so and put it up for review at 
https://reviews.llvm.org/D53691.
2. Write an email to the mailing lists to ask for volunteers for being on the 
“default-cc” list for components, implying you’re willing to triage bugs 
reported against those components. I’ve decided to first try and get consensus 
on what is expected when triaging a bug (see point above) before actively 
searching for volunteers for all components. That being said, both at the dev 
meeting and in the days after, I already received many requests from people to 
be added to the default-cc list for specific components. Of course, I’m very 
happy to add people volunteering to default-cc lists, so if you don’t want to 
wait to get added to a default-cc list, please email 
bugs-ad...@lists.llvm.org or raise it as a 
ticket in bugs.llvm.org under “Bugzilla 
Admin”/“Products”.

Furthermore, since the BoF, I’ve seen a quite a few requests to clean up and 
introduce new components in Bugzilla. We’ve implemented the changes quickly and 
will aim to continue to have a quick response time in the future. Please file a 
ticket in bugs.llvm.org under “Bugzilla 
Admin”/“Products” if you want to request a specific change.

For most of the other points that were raised: I don’t currently plan on acting 
on them immediately myself and hope to first see an impact of the above actions.

In the original post, there was a suggestion to bring back the "UNCONFIRMED" 
status. I think that'd be a great idea, as it both makes it easy to search for 
untriaged bugs and to give feedback to a reporter that their bug is real and 
acknowledged. Is that planned?

I hadn’t seen too much feedback on the idea for introducing (reintroducing?) 
the “UNCONFIRMED” status, so hadn’t planned on making changes to that now.
However, I also think it’s a good idea, so I’ll investigate in more detail now 
if it wouldn’t be overly hard on the Bugzilla admin side to do so (e.g. I 
believe I’ll have to give all existing users the rights to be able to confirm 
bugs). If the “UNCONFIRMED” status can be introduced relatively easily, I now 
plan to do so, and will adapt the proposed documentation at 
https://reviews.llvm.org/D53691 accordingly.
Thanks for pointing to this!

Also, a big problem with bugzilla as we have it configured today is that 
commenting on an existing bug often sends mail to literally no-one. Can we 
reconfigure this so that llvmbugs gets mail for comments on bugs, not just for 
opening and closing bugs?

I see you’ve created https://bugs.llvm.org/show_bug.cgi?id=39445 for this in 
the mean time, and that a bit of discussion has started there - including 
whether sending an email on all comments wouldn’t result in too much spam on 
the llvmbugs mailing list. I don’t have a strong opinion either way myself. I 
hope that making sure that there is at least someone on the default-cc list for 
every component will result in comments on bugs being emailed to at least one 
person.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [RFC] LLVM bug lifecycle BoF - triaging

[via lldb-dev]

As an llvm-bugs subscriber, I would prefer *not* to have email for every 
comment to every bug.  That's what the CC list is for.
If the admins guarantee that there is at least one auto-cc (who promises to pay 
attention) for each component, I think that is sufficient.

Also +1 for UNCONFIRMED.
--paulr

From: Kristof Beyls [mailto:kristof.be...@arm.com]
Sent: Friday, October 26, 2018 10:26 AM
To: Richard Smith
Cc: dean.ber...@gmail.com; llvm-dev; LLDB Dev; Clang Dev; Tanya Lattner; nd; 
Robinson, Paul
Subject: Re: [cfe-dev] [RFC] LLVM bug lifecycle BoF - triaging




On 26 Oct 2018, at 04:26, Richard Smith 
mailto:rich...@metafoo.co.uk>> wrote:

On Thu, 25 Oct 2018 at 05:10, Kristof Beyls via cfe-dev 
mailto:cfe-...@lists.llvm.org>> wrote:
On 5 Oct 2018, at 07:04, Dean Michael Berris 
mailto:dean.ber...@gmail.com>> wrote:

Thank you for starting this conversation! I look forward to the results of the 
BoF discussion summarised as well.

Dean, all,

There was a lively discussion at the BoF; we’ve tried to take notes at 
https://etherpad.net/p/LLVMBugLifeCycleBoF but probably have failed to capture 
all the points. The slides used to kick start the discussion can be found at 
https://docs.google.com/presentation/d/1ERB9IQAjSwaNpEnlbchQzd_V9IQlLOojgo9J0_NXvYA/edit

Both at the BoF and in the mail thread, there have been many suggestions for 
improvements. So many that if we’d want to introduce all of them at once, we’d 
probably get stuck and not introduce any. To try and make progress on the ones 
I myself feel are most useful, I’ve volunteered for 2 actions:

1. Write up a proposal for documentation on what to do during bug 
triaging/closing/etc. I’ve just done so and put it up for review at 
https://reviews.llvm.org/D53691.
2. Write an email to the mailing lists to ask for volunteers for being on the 
“default-cc” list for components, implying you’re willing to triage bugs 
reported against those components. I’ve decided to first try and get consensus 
on what is expected when triaging a bug (see point above) before actively 
searching for volunteers for all components. That being said, both at the dev 
meeting and in the days after, I already received many requests from people to 
be added to the default-cc list for specific components. Of course, I’m very 
happy to add people volunteering to default-cc lists, so if you don’t want to 
wait to get added to a default-cc list, please email 
bugs-ad...@lists.llvm.org or raise it as a 
ticket in bugs.llvm.org under “Bugzilla 
Admin”/“Products”.

Furthermore, since the BoF, I’ve seen a quite a few requests to clean up and 
introduce new components in Bugzilla. We’ve implemented the changes quickly and 
will aim to continue to have a quick response time in the future. Please file a 
ticket in bugs.llvm.org under “Bugzilla 
Admin”/“Products” if you want to request a specific change.

For most of the other points that were raised: I don’t currently plan on acting 
on them immediately myself and hope to first see an impact of the above actions.

In the original post, there was a suggestion to bring back the "UNCONFIRMED" 
status. I think that'd be a great idea, as it both makes it easy to search for 
untriaged bugs and to give feedback to a reporter that their bug is real and 
acknowledged. Is that planned?

I hadn’t seen too much feedback on the idea for introducing (reintroducing?) 
the “UNCONFIRMED” status, so hadn’t planned on making changes to that now.
However, I also think it’s a good idea, so I’ll investigate in more detail now 
if it wouldn’t be overly hard on the Bugzilla admin side to do so (e.g. I 
believe I’ll have to give all existing users the rights to be able to confirm 
bugs). If the “UNCONFIRMED” status can be introduced relatively easily, I now 
plan to do so, and will adapt the proposed documentation at 
https://reviews.llvm.org/D53691 accordingly.
Thanks for pointing to this!


Also, a big problem with bugzilla as we have it configured today is that 
commenting on an existing bug often sends mail to literally no-one. Can we 
reconfigure this so that llvmbugs gets mail for comments on bugs, not just for 
opening and closing bugs?

I see you’ve created https://bugs.llvm.org/show_bug.cgi?id=39445 for this in 
the mean time, and that a bit of discussion has started there - including 
whether sending an email on all comments wouldn’t result in too much spam on 
the llvmbugs mailing list. I don’t have a strong opinion either way myself. I 
hope that making sure that there is at least someone on the default-cc list for 
every component will result in comments on bugs being emailed to at least one 
person.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] [RFC] LLVM bug lifecycle BoF - triaging

[Kristof Beyls via lldb-dev]

On 26 Oct 2018, at 16:25, Kristof Beyls via llvm-dev 
mailto:llvm-...@lists.llvm.org>> wrote:



On 26 Oct 2018, at 04:26, Richard Smith 
mailto:rich...@metafoo.co.uk>> wrote:

On Thu, 25 Oct 2018 at 05:10, Kristof Beyls via cfe-dev 
mailto:cfe-...@lists.llvm.org>> wrote:
On 5 Oct 2018, at 07:04, Dean Michael Berris 
mailto:dean.ber...@gmail.com>> wrote:

Thank you for starting this conversation! I look forward to the results of the 
BoF discussion summarised as well.

Dean, all,

There was a lively discussion at the BoF; we’ve tried to take notes at 
https://etherpad.net/p/LLVMBugLifeCycleBoF but probably have failed to capture 
all the points. The slides used to kick start the discussion can be found at 
https://docs.google.com/presentation/d/1ERB9IQAjSwaNpEnlbchQzd_V9IQlLOojgo9J0_NXvYA/edit

Both at the BoF and in the mail thread, there have been many suggestions for 
improvements. So many that if we’d want to introduce all of them at once, we’d 
probably get stuck and not introduce any. To try and make progress on the ones 
I myself feel are most useful, I’ve volunteered for 2 actions:

1. Write up a proposal for documentation on what to do during bug 
triaging/closing/etc. I’ve just done so and put it up for review at 
https://reviews.llvm.org/D53691.
2. Write an email to the mailing lists to ask for volunteers for being on the 
“default-cc” list for components, implying you’re willing to triage bugs 
reported against those components. I’ve decided to first try and get consensus 
on what is expected when triaging a bug (see point above) before actively 
searching for volunteers for all components. That being said, both at the dev 
meeting and in the days after, I already received many requests from people to 
be added to the default-cc list for specific components. Of course, I’m very 
happy to add people volunteering to default-cc lists, so if you don’t want to 
wait to get added to a default-cc list, please email 
bugs-ad...@lists.llvm.org or raise it as a 
ticket in bugs.llvm.org under “Bugzilla 
Admin”/“Products”.

Furthermore, since the BoF, I’ve seen a quite a few requests to clean up and 
introduce new components in Bugzilla. We’ve implemented the changes quickly and 
will aim to continue to have a quick response time in the future. Please file a 
ticket in bugs.llvm.org under “Bugzilla 
Admin”/“Products” if you want to request a specific change.

For most of the other points that were raised: I don’t currently plan on acting 
on them immediately myself and hope to first see an impact of the above actions.

In the original post, there was a suggestion to bring back the "UNCONFIRMED" 
status. I think that'd be a great idea, as it both makes it easy to search for 
untriaged bugs and to give feedback to a reporter that their bug is real and 
acknowledged. Is that planned?

I hadn’t seen too much feedback on the idea for introducing (reintroducing?) 
the “UNCONFIRMED” status, so hadn’t planned on making changes to that now.
However, I also think it’s a good idea, so I’ll investigate in more detail now 
if it wouldn’t be overly hard on the Bugzilla admin side to do so (e.g. I 
believe I’ll have to give all existing users the rights to be able to confirm 
bugs). If the “UNCONFIRMED” status can be introduced relatively easily, I now 
plan to do so, and will adapt the proposed documentation at 
https://reviews.llvm.org/D53691 accordingly.
Thanks for pointing to this!

Just a status update on investigations to enable the UNCONFIRMED/CONFIRMED 
states: it seems that bugzilla by-default will put bugs in the “CONFIRMED” 
state when creating new bugs, if the reporter has “can-confirm” rights. I 
believe our de facto policy is for everyone with an account to be able to 
confirm bugs. Also, you need an account to be able to report a bug. The result 
is that all new bugs by default will go to status “CONFIRMED”, unless the 
reporter carefully remembers to change the default and select “UNCONFIRMED”. 
(Also see https://bugzilla.mozilla.org/show_bug.cgi?id=915682 which suggests 
this behaviour is not configurable).

Unless that can be solved, I fear that many bugs will be reported with the 
default “CONFIRMED” status even though they aren’t triaged yet. I believe that 
is worse than the current default “NEW” state.

The only work around for this behaviour where we still get a “to be triaged” 
state I can think of at the moment is to introduce a custom “CONFIRMED” status, 
not using bugzilla’s built-in special “UNCONFIRMED” support and have a flow 
that would allow something like:

NEW -> CONFIRMED -> ASSIGNED -> RESOLVED -> …

The advantage is we’d have separate states to represent “this bug was raised” 
(NEW) vs “this bug was triaged & confirmed” (CONFIRMED).
The disadvantage is that we’ll start deviating from the default bugzilla 
workflows.

Overall, I think it’s still a win to implement the above idea. I’ll look into 
that next

Re: [lldb-dev] Problem formatting class types

[Jim Ingham via lldb-dev]

The data formatters don't currently have a  specified language.  We should 
maybe add that and then we could only load formatters for a language when its 
runtime gets loaded.  Then they could also know to turn themselves on and off 
based on the language of the current frame, or of the current expression.  We 
have to be careful, because UIKit and AppKit have a bunch of interesting 
globals that show the state of the UI, and it very common for folks to just 
interrupt the debugger anywhere and run ObjC expressions (even though the frame 
language is not ObjC) and expect them and the associated formatters to work.  
Breaking that expectation would be pretty disruptive.

But at the minimum, not loading formatters for a language that we can determine 
isn't used in this program seems like something we should try to avoid.

You can work around this in the short term by doing either:

(lldb) type category disable objc
(lldb) expr myClass
(Class) $5 = {
  x = 0
  y = 1
  z = 'z'
}

Or if you don't want to change global settings, use:

(lldb) expr --raw -- myClass
(Class) $3 = {
  x = 0
  y = 1
  z = 'z'
}

Jim


> On Oct 26, 2018, at 3:29 AM, Zachary Turner via lldb-dev 
>  wrote:
> 
> Note that I also tried this with a a linux / DWARF executable and had the 
> same result.
> 
> On Fri, Oct 26, 2018 at 3:21 AM Zachary Turner  wrote:
> Hello,
> 
> I've got this code:
> 
> class Class {
>   int x = 0;
>   short y = 1;
>   char z = 'z';
> } C;
> 
> int main(int argc, char **argv) {
>   __debugbreak();
>   return 0;
> }
> 
> and I run the following LLDB session:
> 
> lldb.exe -f foo.exe
> (lldb) target create "foo.exe"
> Current executable set to 'foo.exe' (x86_64).
> (lldb) run
> Process 24604 launched: 'foo.exe' (x86_64)
> Process 24604 stopped
> * thread #1, stop reason = Exception 0x8003 encountered at address 
> 0x7ff70a0b1017
> frame #0: 0x7ff70a0b1018 foo.exe`main(argc=-1123614720, 
> argv=0x7ff70a0b1000) at foo.cpp:19
>16
>17   int main(int argc, char **argv) {
>18 __debugbreak();
> -> 19 return 0;
>20   }
> (lldb) p C
> (Class) $0 =
> (lldb)
> 
> The issue is, of course, that it doesn't display the members of the class C.  
> The type support in PDB is fine, so it's not that.  For example:
> 
> (lldb) type lookup Class
> class Class {
> int x;
> short y;
> char z;
> }
> 
> And it can definitely find C in memory:
> 
> (lldb) p &C
> (Class *) $1 = 0x7ff70a0b3000
> 
> Instead, the issue seems to be related to the value object formatter.  I 
> tried to track this down but this code is pretty complicated.  However, there 
> are two issues that I was able to discover:
> 
> 1) It's using the objective C class formatter.  Obviously I'm not using 
> objective C, so that seems wrong right off the bat.  Specifically, the 
> "Synthetic children front end" is the ObjCClassSyntheticChildrenFrontEnd.  
> 
> 2) Because of #1, when it calls CalculateNumChildren() in Cocoa.cpp, it 
> returns 0.  I would expect it to be calling some function somewhere that 
> returns 3, because there are 3 members of the class.
> 
> What's strange is that I don't see anything in the CPlusPlusLanguage plugin 
> that provides a SyntheticChildrenFrontEnd that examines the CxxRecordDecl and 
> looks for children, so I don't know how this is supposed to work anywhere.  
> But I know it must work somewhere, so I assume I'm just missing something and 
> I need to find out the right place to hook A up to B and things will just 
> work.
> 
> Any pointers on what the expected code path that this should be taking is, so 
> I can try to figure out where I might be going off path?
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Problem formatting class types

[Jim Ingham via lldb-dev]

Remove the "not"...

Jim

> On Oct 26, 2018, at 10:24 AM, Jim Ingham  wrote:
> 
> But at the minimum, not loading formatters for a language that we can 
> determine isn't used in this program seems like something we should try to 
> avoid.

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 39459] New: Enum class variables can't be used as function arguments

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=39459

Bug ID: 39459
   Summary: Enum class variables can't be used as function
arguments
   Product: lldb
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: clayb...@gmail.com
CC: llvm-b...@lists.llvm.org

Compile the following code
enum class Foo : short {
  a,b,c
};

bool UseFoo(Foo f) {
  return (bool)f;
}

int main() {
  Foo foo = Foo::a;
  auto r = UseFoo(foo); // breakpoint
}

Then debug it and try to call "UseFoo" with an enumeration:

$ lldb a.out 
(lldb) target create "a.out"
(lldb) b /breakpoint/
(lldb) r
Process 98692 launched: '/tmp/a.out' (x86_64)
Process 98692 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x00010f9e a.out`main at /tmp/main.cpp:11
   8
   9int main() {
   10 Foo foo = Foo::a;
-> 11 auto r = UseFoo(foo); // breakpoint
   12   }
   13   
Target 0: (a.out) stopped.
(lldb) p UseFoo(Foo::b)
error: no matching function for call to 'UseFoo'
candidate function not viable: no known conversion from 'short' to 'Foo' for
1st argument
(lldb) p UseFoo((Foo)Foo::b)
(bool) $0 = true

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 39459] Enum class variables can't be used as function arguments

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=39459

Frederic Riss  changed:

   What|Removed |Added

   Assignee|lldb-dev@lists.llvm.org |syaghm...@gmail.com
 CC||fr...@apple.com

--- Comment #1 from Frederic Riss  ---
Shafik, isn't this the issue you were looking at?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Problem formatting class types

[Zachary Turner via lldb-dev]

So, the second command works, but the first one doesn't.  It doesn't give
any error, but on the other hand, it doesn't change the results of printing
the variable.  When I run type category list though, I get this:

(lldb) type category list
Category: default (enabled)
Category: VectorTypes (enabled, applicable for language(s): objective-c++)
Category: system (enabled, applicable for language(s): objective-c++)

So it looks like the behavior I'm seeing is already with the default
category.  Does this sound right?  Which code path is supposed to get
executed to format it as a C++ class?

On Fri, Oct 26, 2018 at 10:25 AM Jim Ingham  wrote:

> Remove the "not"...
>
> Jim
>
> > On Oct 26, 2018, at 10:24 AM, Jim Ingham  wrote:
> >
> > But at the minimum, not loading formatters for a language that we can
> determine isn't used in this program seems like something we should try to
> avoid.
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Problem formatting class types

[Jim Ingham via lldb-dev]

Most C++ classes and C structs don't have data formatters, particularly not 
classes that you write yourself.  

The way value printing works in lldb is that we start by making the ValueObject 
for the value from its Type, so at that stage it is just a direct view of the 
members of the object.  That is done without help of the data formatters, 
reading instead directly from the object's type.  Then we consult our type 
match -> summary/synthetic children registries and we construct a summary or a 
set of "synthetic children" (or both) for the object if we find any matches 
there.  Then the ValueObjectPrinter prints the object using the Type based 
ValueObject, the Summary and the Synthetic Children, and there's a print 
options object that says whether to use the raw view, the summary and/or the 
synthetic children.

But for a type lldb knows nothing about, there won't be any entries in the 
formatter maps, so you should just see the direct Type based children in that 
case.

--raw sets the right options in the print option object to get the printer to 
just use the strict Type based view of the object, with no formatters applied.

In your case, you used "Class" as your type name and  Class is a special name 
in ObjC and there happens to be a formatter for that.  You can always figure 
out what formatters apply to the result of an expression with the "type 
{summary/synthetic} info" command.  For your example, I see (my variable of 
type Class was called myClass):

(lldb) type summary info myClass
summary applied to (Class) myClass is:  (not cascading) (hide value) (skip 
pointers) (skip references) Class summary provider
(lldb) type synthetic info myClass
synthetic applied to (Class) myClass is:  Class synthetic children

On macOS those summary/synthetic child providers are in the objc category.  The 
info output should really print the category as well, that would be helpful.  
But you can do "type summary list" and then find the summary in that list and 
go from there to the category.  Ditto for "type synthetic".

What do you get from that?

Jim

> On Oct 26, 2018, at 3:34 PM, Zachary Turner  wrote:
> 
> So, the second command works, but the first one doesn't.  It doesn't give any 
> error, but on the other hand, it doesn't change the results of printing the 
> variable.  When I run type category list though, I get this:
> 
> (lldb) type category list
> Category: default (enabled)
> Category: VectorTypes (enabled, applicable for language(s): objective-c++)
> Category: system (enabled, applicable for language(s): objective-c++)
> 
> So it looks like the behavior I'm seeing is already with the default 
> category.  Does this sound right?  Which code path is supposed to get 
> executed to format it as a C++ class?
> 
> On Fri, Oct 26, 2018 at 10:25 AM Jim Ingham  wrote:
> Remove the "not"...
> 
> Jim
> 
> > On Oct 26, 2018, at 10:24 AM, Jim Ingham  wrote:
> > 
> > But at the minimum, not loading formatters for a language that we can 
> > determine isn't used in this program seems like something we should try to 
> > avoid.
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Problem formatting class types

[Zachary Turner via lldb-dev]

Ok that was it, it was because my type was called Class. Oops!
On Fri, Oct 26, 2018 at 4:28 PM Jim Ingham  wrote:

> Most C++ classes and C structs don't have data formatters, particularly
> not classes that you write yourself.
>
> The way value printing works in lldb is that we start by making the
> ValueObject for the value from its Type, so at that stage it is just a
> direct view of the members of the object.  That is done without help of the
> data formatters, reading instead directly from the object's type.  Then we
> consult our type match -> summary/synthetic children registries and we
> construct a summary or a set of "synthetic children" (or both) for the
> object if we find any matches there.  Then the ValueObjectPrinter prints
> the object using the Type based ValueObject, the Summary and the Synthetic
> Children, and there's a print options object that says whether to use the
> raw view, the summary and/or the synthetic children.
>
> But for a type lldb knows nothing about, there won't be any entries in the
> formatter maps, so you should just see the direct Type based children in
> that case.
>
> --raw sets the right options in the print option object to get the printer
> to just use the strict Type based view of the object, with no formatters
> applied.
>
> In your case, you used "Class" as your type name and  Class is a special
> name in ObjC and there happens to be a formatter for that.  You can always
> figure out what formatters apply to the result of an expression with the
> "type {summary/synthetic} info" command.  For your example, I see (my
> variable of type Class was called myClass):
>
> (lldb) type summary info myClass
> summary applied to (Class) myClass is:  (not cascading) (hide value) (skip
> pointers) (skip references) Class summary provider
> (lldb) type synthetic info myClass
> synthetic applied to (Class) myClass is:  Class synthetic children
>
> On macOS those summary/synthetic child providers are in the objc
> category.  The info output should really print the category as well, that
> would be helpful.  But you can do "type summary list" and then find the
> summary in that list and go from there to the category.  Ditto for "type
> synthetic".
>
> What do you get from that?
>
> Jim
>
> > On Oct 26, 2018, at 3:34 PM, Zachary Turner  wrote:
> >
> > So, the second command works, but the first one doesn't.  It doesn't
> give any error, but on the other hand, it doesn't change the results of
> printing the variable.  When I run type category list though, I get this:
> >
> > (lldb) type category list
> > Category: default (enabled)
> > Category: VectorTypes (enabled, applicable for language(s):
> objective-c++)
> > Category: system (enabled, applicable for language(s): objective-c++)
> >
> > So it looks like the behavior I'm seeing is already with the default
> category.  Does this sound right?  Which code path is supposed to get
> executed to format it as a C++ class?
> >
> > On Fri, Oct 26, 2018 at 10:25 AM Jim Ingham  wrote:
> > Remove the "not"...
> >
> > Jim
> >
> > > On Oct 26, 2018, at 10:24 AM, Jim Ingham  wrote:
> > >
> > > But at the minimum, not loading formatters for a language that we can
> determine isn't used in this program seems like something we should try to
> avoid.
> >
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev