[Lldb-commits] [PATCH] D136011: [lldb] Don't check environment default char signedness when creating clang type for "char"

dblaikie added a comment. In D136011#3870677 , @labath wrote: > In D136011#3866854 , @aeubanks > wrote: > >> In D136011#3862150 , @labath wrote: >> >>> >> >> Maybe looki

[Lldb-commits] [PATCH] D136011: [lldb] Don't check environment default char signedness when creating clang type for "char"

This revision was automatically updated to reflect the committed changes. Closed by commit rGba8ded6820fa: [lldb] Don't check environment default char signedness when creating clang type… (authored by aeubanks). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.ll

[Lldb-commits] [PATCH] D136011: [lldb] Don't check environment default char signedness when creating clang type for "char"

labath accepted this revision. labath added a comment. This revision is now accepted and ready to land. In D136011#3866854 , @aeubanks wrote: > In D136011#3862150 , @labath wrote: > >> > > Maybe looking for a "ch

[Lldb-commits] [PATCH] D136011: [lldb] Don't check environment default char signedness when creating clang type for "char"

dblaikie added a comment. In D136011#3862150 , @labath wrote: > In D136011#3860637 , @dblaikie > wrote: > >> I think the place where this will go wrong is in terms of how lldb renders >> `char` values on non-def

[Lldb-commits] [PATCH] D136011: [lldb] Don't check environment default char signedness when creating clang type for "char"

aeubanks added a comment. In D136011#3862150 , @labath wrote: > In D136011#3860637 , @dblaikie > wrote: > >> I think the place where this will go wrong is in terms of how lldb renders >> `char` values on non-def

[Lldb-commits] [PATCH] D136011: [lldb] Don't check environment default char signedness when creating clang type for "char"

labath added a comment. In D136011#3860637 , @dblaikie wrote: > I think the place where this will go wrong is in terms of how lldb renders > `char` values on non-default-char-signedness programs (it'll render them as > the default-char-signedness, which

[Lldb-commits] [PATCH] D136011: [lldb] Don't check environment default char signedness when creating clang type for "char"

DavidSpickett added a comment. > With -f(un)signed-char, the die corresponding to "char" may be the wrong > DW_ATE_(un)signed_char. As the producer of the DWARF (so, clang for example) is this correct by the existing rules? As I understand it so far, if the compiler is using "char" (no sign ch

[Lldb-commits] [PATCH] D136011: [lldb] Don't check environment default char signedness when creating clang type for "char"

aeubanks updated this revision to Diff 468118. aeubanks added a comment. update test Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D136011/new/ https://reviews.llvm.org/D136011 Files: lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp lld

[Lldb-commits] [PATCH] D136011: [lldb] Don't check environment default char signedness when creating clang type for "char"

dblaikie added a comment. I think the place where this will go wrong is in terms of how lldb renders `char` values on non-default-char-signedness programs (it'll render them as the default-char-signedness, which might be confusing to a user - since they'll be looking at literals, etc, that are

[Lldb-commits] [PATCH] D136011: [lldb] Don't check environment default char signedness when creating clang type for "char"

aeubanks added a comment. not 100% sure this is the right fix Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D136011/new/ https://reviews.llvm.org/D136011 ___ lldb-commits mailing list lldb-commits@lists.l

[Lldb-commits] [PATCH] D136011: [lldb] Don't check environment default char signedness when creating clang type for "char"

aeubanks created this revision. Herald added a project: All. aeubanks requested review of this revision. Herald added a project: LLDB. Herald added a subscriber: lldb-commits. With -f(un)signed-char, the die corresponding to "char" may be the wrong DW_ATE_(un)signed_char. Ultimately we can determ