RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-23 03:02:36 +01:00
Code Issues Projects Releases Wiki Activity
d8b6f240a9
llvm-mirror/test/Demangle/ms-templates-memptrs.test

97 lines
3.6 KiB
Plaintext
Raw Normal View History

[MS Demangler] Demangle member pointer template parameters. llvm-svn: 340199
2018-08-20 21:15:35 +02:00
; RUN: llvm-undname < %s | FileCheck %s
; CHECK-NOT: Invalid mangled name
??$CallMethod@UC@NegativeNVOffset@@$I??_912@$BA@AEPPPPPPPM@A@@@YAXAAUC@NegativeNVOffset@@@Z
[MS Demangler] Re-write the Microsoft demangler. This is a pretty large refactor / re-write of the Microsoft demangler. The previous one was a little hackish because it evolved as I was learning about all the various edge cases, exceptions, etc. It didn't have a proper AST and so there was lots of custom handling of things that should have been much more clean. Taking what was learned from that experience, it's now re-written with a completely redesigned and much more sensible AST. It's probably still not perfect, but at least it's comprehensible now to someone else who wants to come along and make some modifications or read the code. Incidentally, this fixed a couple of bugs, so I've enabled the tests which now pass. llvm-svn: 340710
2018-08-27 05:48:03 +02:00
; CHECK: void __cdecl CallMethod<struct NegativeNVOffset::C, {[thunk]: __thiscall NegativeNVOffset::C::`vcall'{0, {flat}}, 4294967292, 0}>(struct NegativeNVOffset::C &)
[MS Demangler] Demangle member pointer template parameters. llvm-svn: 340199
2018-08-20 21:15:35 +02:00
??$CallMethod@UM@@$0A@@@YAXAAUM@@@Z
; CHECK: void __cdecl CallMethod<struct M, 0>(struct M &)
??$CallMethod@UM@@$H??_91@$BA@AEA@@@YAXAAUM@@@Z
[MS Demangler] Re-write the Microsoft demangler. This is a pretty large refactor / re-write of the Microsoft demangler. The previous one was a little hackish because it evolved as I was learning about all the various edge cases, exceptions, etc. It didn't have a proper AST and so there was lots of custom handling of things that should have been much more clean. Taking what was learned from that experience, it's now re-written with a completely redesigned and much more sensible AST. It's probably still not perfect, but at least it's comprehensible now to someone else who wants to come along and make some modifications or read the code. Incidentally, this fixed a couple of bugs, so I've enabled the tests which now pass. llvm-svn: 340710
2018-08-27 05:48:03 +02:00
; CHECK: void __cdecl CallMethod<struct M, {[thunk]: __thiscall M::`vcall'{0, {flat}}, 0}>(struct M &)
[MS Demangler] Demangle member pointer template parameters. llvm-svn: 340199
2018-08-20 21:15:35 +02:00
??$CallMethod@UM@@$H?f@1@QAEXXZA@@@YAXAAUM@@@Z
[MS Demangler] Print public:, protected:, private: if set in FunctionClass or a variable's StorageClass. undname prints them, and the information is in the decorated name, so we probably shouldn't lose it when undecorating. I spot-checked a few of the funnier-looking outputs, and undname has the same output. Differential Revision: https://reviews.llvm.org/D54396 llvm-svn: 346791
2018-11-13 21:18:26 +01:00
; CHECK: void __cdecl CallMethod<struct M, {public: void __thiscall M::f(void), 0}>(struct M &)
[MS Demangler] Demangle member pointer template parameters. llvm-svn: 340199
2018-08-20 21:15:35 +02:00
??$CallMethod@UO@@$H??_91@$BA@AE3@@YAXAAUO@@@Z
[MS Demangler] Re-write the Microsoft demangler. This is a pretty large refactor / re-write of the Microsoft demangler. The previous one was a little hackish because it evolved as I was learning about all the various edge cases, exceptions, etc. It didn't have a proper AST and so there was lots of custom handling of things that should have been much more clean. Taking what was learned from that experience, it's now re-written with a completely redesigned and much more sensible AST. It's probably still not perfect, but at least it's comprehensible now to someone else who wants to come along and make some modifications or read the code. Incidentally, this fixed a couple of bugs, so I've enabled the tests which now pass. llvm-svn: 340710
2018-08-27 05:48:03 +02:00
; CHECK: void __cdecl CallMethod<struct O, {[thunk]: __thiscall O::`vcall'{0, {flat}}, 4}>(struct O &)
[MS Demangler] Demangle member pointer template parameters. llvm-svn: 340199
2018-08-20 21:15:35 +02:00
??$CallMethod@US@@$0A@@@YAXAAUS@@@Z
; CHECK: void __cdecl CallMethod<struct S, 0>(struct S &)
??$CallMethod@US@@$1??_91@$BA@AE@@YAXAAUS@@@Z
; CHECK: void __cdecl CallMethod<struct S, &[thunk]: __thiscall S::`vcall'{0, {flat}}>(struct S &)
??$CallMethod@US@@$1?f@1@QAEXXZ@@YAXAAUS@@@Z
[MS Demangler] Print public:, protected:, private: if set in FunctionClass or a variable's StorageClass. undname prints them, and the information is in the decorated name, so we probably shouldn't lose it when undecorating. I spot-checked a few of the funnier-looking outputs, and undname has the same output. Differential Revision: https://reviews.llvm.org/D54396 llvm-svn: 346791
2018-11-13 21:18:26 +01:00
; CHECK: void __cdecl CallMethod<struct S, &public: void __thiscall S::f(void)>(struct S &)
[MS Demangler] Demangle member pointer template parameters. llvm-svn: 340199
2018-08-20 21:15:35 +02:00
??$CallMethod@UU@@$0A@@@YAXAAUU@@@Z
; CHECK: void __cdecl CallMethod<struct U, 0>(struct U &)
??$CallMethod@UU@@$J??_91@$BA@AEA@A@A@@@YAXAAUU@@@Z
; CHECK: void __cdecl CallMethod<struct U, {[thunk]: __thiscall U::`vcall'{0, {flat}}, 0, 0, 0}>(struct U &)
??$CallMethod@UU@@$J?f@1@QAEXXZA@A@A@@@YAXAAUU@@@Z
[MS Demangler] Print public:, protected:, private: if set in FunctionClass or a variable's StorageClass. undname prints them, and the information is in the decorated name, so we probably shouldn't lose it when undecorating. I spot-checked a few of the funnier-looking outputs, and undname has the same output. Differential Revision: https://reviews.llvm.org/D54396 llvm-svn: 346791
2018-11-13 21:18:26 +01:00
; CHECK: void __cdecl CallMethod<struct U, {public: void __thiscall U::f(void), 0, 0, 0}>(struct U &)
[MS Demangler] Demangle member pointer template parameters. llvm-svn: 340199
2018-08-20 21:15:35 +02:00
??$CallMethod@UV@@$0A@@@YAXAAUV@@@Z
; CHECK: void __cdecl CallMethod<struct V, 0>(struct V &)
??$CallMethod@UV@@$I??_91@$BA@AEA@A@@@YAXAAUV@@@Z
; CHECK: void __cdecl CallMethod<struct V, {[thunk]: __thiscall V::`vcall'{0, {flat}}, 0, 0}>(struct V &)
??$CallMethod@UV@@$I?f@1@QAEXXZA@A@@@YAXAAUV@@@Z
[MS Demangler] Print public:, protected:, private: if set in FunctionClass or a variable's StorageClass. undname prints them, and the information is in the decorated name, so we probably shouldn't lose it when undecorating. I spot-checked a few of the funnier-looking outputs, and undname has the same output. Differential Revision: https://reviews.llvm.org/D54396 llvm-svn: 346791
2018-11-13 21:18:26 +01:00
; CHECK: void __cdecl CallMethod<struct V, {public: void __thiscall V::f(void), 0, 0}>(struct V &)
[MS Demangler] Demangle member pointer template parameters. llvm-svn: 340199
2018-08-20 21:15:35 +02:00
??$ReadField@UA@@$0?0@@YAHAAUA@@@Z
; CHECK: int __cdecl ReadField<struct A, -1>(struct A &)
??$ReadField@UA@@$0A@@@YAHAAUA@@@Z
; CHECK: int __cdecl ReadField<struct A, 0>(struct A &)
??$ReadField@UI@@$03@@YAHAAUI@@@Z
; CHECK: int __cdecl ReadField<struct I, 4>(struct I &)
??$ReadField@UI@@$0A@@@YAHAAUI@@@Z
; CHECK: int __cdecl ReadField<struct I, 0>(struct I &)
??$ReadField@UM@@$0A@@@YAHAAUM@@@Z
; CHECK: int __cdecl ReadField<struct M, 0>(struct M &)
??$ReadField@UM@@$0BA@@@YAHAAUM@@@Z
; CHECK: int __cdecl ReadField<struct M, 16>(struct M &)
??$ReadField@UM@@$0M@@@YAHAAUM@@@Z
; CHECK: int __cdecl ReadField<struct M, 12>(struct M &)
??$ReadField@US@@$03@@YAHAAUS@@@Z
; CHECK: int __cdecl ReadField<struct S, 4>(struct S &)
??$ReadField@US@@$07@@YAHAAUS@@@Z
; CHECK: int __cdecl ReadField<struct S, 8>(struct S &)
??$ReadField@US@@$0A@@@YAHAAUS@@@Z
; CHECK: int __cdecl ReadField<struct S, 0>(struct S &)
??$ReadField@UU@@$0A@@@YAHAAUU@@@Z
; CHECK: int __cdecl ReadField<struct U, 0>(struct U &)
??$ReadField@UU@@$G3A@A@@@YAHAAUU@@@Z
; CHECK: int __cdecl ReadField<struct U, {4, 0, 0}>(struct U &)
??$ReadField@UU@@$G7A@A@@@YAHAAUU@@@Z
; CHECK: int __cdecl ReadField<struct U, {8, 0, 0}>(struct U &)
??$ReadField@UV@@$0A@@@YAHAAUV@@@Z
; CHECK: int __cdecl ReadField<struct V, 0>(struct V &)
??$ReadField@UV@@$F7A@@@YAHAAUV@@@Z
; CHECK: int __cdecl ReadField<struct V, {8, 0}>(struct V &)
??$ReadField@UV@@$FM@A@@@YAHAAUV@@@Z
; CHECK: int __cdecl ReadField<struct V, {12, 0}>(struct V &)
[MS Demangler] Fix a few more edge cases. I found these by running llvm-undname over a couple hundred megabytes of object files generated as part of building chromium. The issues fixed in this patch are: 1) decltype-auto return types. 2) Indirect vtables (e.g. const A::`vftable'{for `B'}) 3) Pointers, references, and rvalue-references to member pointers. I have exactly one remaining symbol out of a few hundred MB of object files that produces a name we can't demangle, and it's related to back-referencing. llvm-svn: 340341
2018-08-21 23:23:49 +02:00
?Q@@3$$QEAP8Foo@@EAAXXZEA
; CHECK: void (__cdecl Foo::*&&Q)(void)
Reference in New Issue Copy Permalink