RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-20 19:42:54 +02:00
Code Issues Projects Releases Wiki Activity
10305a8da8
llvm-mirror/test/Demangle/ms-nested-scopes.test

150 lines
6.3 KiB
Plaintext
Raw Normal View History

[MS Demangler] Demangle symbols in function scopes. There are a couple of issues you run into when you start getting into more complex names, especially with regards to function local statics. When you've got something like: int x() { static int n = 0; return n; } Then this needs to demangle to something like int `int __cdecl x()'::`1'::n The nested mangled symbols (e.g. `int __cdecl x()` in the above example) also share state with regards to back-referencing, so we need to be able to re-use the demangler in the middle of demangling a symbol while sharing back-ref state. To make matters more complicated, there are a lot of ambiguities when demangling a symbol's qualified name, because a function local scope pattern (usually something like `?1??name?`) looks suspiciously like many other possible things that can occur, such as `?1` meaning the second back-ref and disambiguating these cases is rather interesting. The `?1?` in a local scope pattern is actually a special case of the more general pattern of `? + <encoded number> + ?`, where "encoded number" can itself have embedded `@` symbols, which is a common delimeter in mangled names. So we have to take care during the disambiguation, which is the reason for the overly complicated `isLocalScopePattern` function in this patch. I've added some pretty obnoxious tests to exercise all of this, which exposed several other problems related to back-referencing, so those are fixed here as well. Finally, I've uncommented some tests that were previously marked as `FIXME`, since now these work. Differential Revision: https://reviews.llvm.org/D49965 llvm-svn: 338226
2018-07-30 05:12:34 +02:00
; RUN: llvm-undname < %s | FileCheck %s
; CHECK-NOT: Invalid mangled name
; Test demangling of function local scope discriminator IDs.
?M@?@??L@@YAHXZ@4HA
; CHECK: int `int __cdecl L(void)'::`0'::M
?M@?0??L@@YAHXZ@4HA
; CHECK: int `int __cdecl L(void)'::`1'::M
?M@?1??L@@YAHXZ@4HA
; CHECK: int `int __cdecl L(void)'::`2'::M
?M@?2??L@@YAHXZ@4HA
; CHECK: int `int __cdecl L(void)'::`3'::M
?M@?3??L@@YAHXZ@4HA
; CHECK: int `int __cdecl L(void)'::`4'::M
?M@?4??L@@YAHXZ@4HA
; CHECK: int `int __cdecl L(void)'::`5'::M
?M@?5??L@@YAHXZ@4HA
; CHECK: int `int __cdecl L(void)'::`6'::M
?M@?6??L@@YAHXZ@4HA
; CHECK: int `int __cdecl L(void)'::`7'::M
?M@?7??L@@YAHXZ@4HA
; CHECK: int `int __cdecl L(void)'::`8'::M
?M@?8??L@@YAHXZ@4HA
; CHECK: int `int __cdecl L(void)'::`9'::M
?M@?9??L@@YAHXZ@4HA
; CHECK: int `int __cdecl L(void)'::`10'::M
?M@?L@??L@@YAHXZ@4HA
; CHECK: int `int __cdecl L(void)'::`11'::M
?M@?M@??L@@YAHXZ@4HA
; CHECK: int `int __cdecl L(void)'::`12'::M
?M@?N@??L@@YAHXZ@4HA
; CHECK: int `int __cdecl L(void)'::`13'::M
?M@?O@??L@@YAHXZ@4HA
; CHECK: int `int __cdecl L(void)'::`14'::M
?M@?P@??L@@YAHXZ@4HA
; CHECK: int `int __cdecl L(void)'::`15'::M
?M@?BA@??L@@YAHXZ@4HA
; CHECK: int `int __cdecl L(void)'::`16'::M
?M@?BB@??L@@YAHXZ@4HA
; CHECK: int `int __cdecl L(void)'::`17'::M
?j@?1??L@@YAHXZ@4UJ@@A
; CHECK: struct J `int __cdecl L(void)'::`2'::j
; Test demangling of name back-references
?NN@0XX@@3HA
; CHECK: int XX::NN::NN
?MM@0NN@XX@@3HA
; CHECK: int XX::NN::MM::MM
?NN@MM@0XX@@3HA
; CHECK: int XX::NN::MM::NN
?OO@0NN@01XX@@3HA
; CHECK: int XX::NN::OO::NN::OO::OO
?NN@OO@010XX@@3HA
; CHECK: int XX::NN::OO::NN::OO::NN
; Test demangling of name back-references combined with function local scopes.
?M@?1??0@YAHXZ@4HA
; CHECK: int `int __cdecl M(void)'::`2'::M
?L@?2??M@0?2??0@YAHXZ@QEAAHXZ@4HA
[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: int `public: int __cdecl `int __cdecl L(void)'::`3'::L::M(void)'::`3'::L
[MS Demangler] Demangle symbols in function scopes. There are a couple of issues you run into when you start getting into more complex names, especially with regards to function local statics. When you've got something like: int x() { static int n = 0; return n; } Then this needs to demangle to something like int `int __cdecl x()'::`1'::n The nested mangled symbols (e.g. `int __cdecl x()` in the above example) also share state with regards to back-referencing, so we need to be able to re-use the demangler in the middle of demangling a symbol while sharing back-ref state. To make matters more complicated, there are a lot of ambiguities when demangling a symbol's qualified name, because a function local scope pattern (usually something like `?1??name?`) looks suspiciously like many other possible things that can occur, such as `?1` meaning the second back-ref and disambiguating these cases is rather interesting. The `?1?` in a local scope pattern is actually a special case of the more general pattern of `? + <encoded number> + ?`, where "encoded number" can itself have embedded `@` symbols, which is a common delimeter in mangled names. So we have to take care during the disambiguation, which is the reason for the overly complicated `isLocalScopePattern` function in this patch. I've added some pretty obnoxious tests to exercise all of this, which exposed several other problems related to back-referencing, so those are fixed here as well. Finally, I've uncommented some tests that were previously marked as `FIXME`, since now these work. Differential Revision: https://reviews.llvm.org/D49965 llvm-svn: 338226
2018-07-30 05:12:34 +02:00
?M@?2??0L@?2??1@YAHXZ@QEAAHXZ@4HA
[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: int `public: int __cdecl `int __cdecl L(void)'::`3'::L::M(void)'::`3'::M
[MS Demangler] Demangle symbols in function scopes. There are a couple of issues you run into when you start getting into more complex names, especially with regards to function local statics. When you've got something like: int x() { static int n = 0; return n; } Then this needs to demangle to something like int `int __cdecl x()'::`1'::n The nested mangled symbols (e.g. `int __cdecl x()` in the above example) also share state with regards to back-referencing, so we need to be able to re-use the demangler in the middle of demangling a symbol while sharing back-ref state. To make matters more complicated, there are a lot of ambiguities when demangling a symbol's qualified name, because a function local scope pattern (usually something like `?1??name?`) looks suspiciously like many other possible things that can occur, such as `?1` meaning the second back-ref and disambiguating these cases is rather interesting. The `?1?` in a local scope pattern is actually a special case of the more general pattern of `? + <encoded number> + ?`, where "encoded number" can itself have embedded `@` symbols, which is a common delimeter in mangled names. So we have to take care during the disambiguation, which is the reason for the overly complicated `isLocalScopePattern` function in this patch. I've added some pretty obnoxious tests to exercise all of this, which exposed several other problems related to back-referencing, so those are fixed here as well. Finally, I've uncommented some tests that were previously marked as `FIXME`, since now these work. Differential Revision: https://reviews.llvm.org/D49965 llvm-svn: 338226
2018-07-30 05:12:34 +02:00
; Function local scopes of template functions
?M@?1???$L@H@@YAHXZ@4HA
; CHECK: int `int __cdecl L<int>(void)'::`2'::M
; And member functions of template classes
?SN@?$NS@H@NS@@QEAAHXZ
; CHECK: int __cdecl NS::NS<int>::SN(void)
?NS@?1??SN@?$NS@H@0@QEAAHXZ@4HA
[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: int `public: int __cdecl NS::NS<int>::SN(void)'::`2'::NS
[MS Demangler] Demangle symbols in function scopes. There are a couple of issues you run into when you start getting into more complex names, especially with regards to function local statics. When you've got something like: int x() { static int n = 0; return n; } Then this needs to demangle to something like int `int __cdecl x()'::`1'::n The nested mangled symbols (e.g. `int __cdecl x()` in the above example) also share state with regards to back-referencing, so we need to be able to re-use the demangler in the middle of demangling a symbol while sharing back-ref state. To make matters more complicated, there are a lot of ambiguities when demangling a symbol's qualified name, because a function local scope pattern (usually something like `?1??name?`) looks suspiciously like many other possible things that can occur, such as `?1` meaning the second back-ref and disambiguating these cases is rather interesting. The `?1?` in a local scope pattern is actually a special case of the more general pattern of `? + <encoded number> + ?`, where "encoded number" can itself have embedded `@` symbols, which is a common delimeter in mangled names. So we have to take care during the disambiguation, which is the reason for the overly complicated `isLocalScopePattern` function in this patch. I've added some pretty obnoxious tests to exercise all of this, which exposed several other problems related to back-referencing, so those are fixed here as well. Finally, I've uncommented some tests that were previously marked as `FIXME`, since now these work. Differential Revision: https://reviews.llvm.org/D49965 llvm-svn: 338226
2018-07-30 05:12:34 +02:00
?SN@?1??0?$NS@H@NS@@QEAAHXZ@4HA
[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: int `public: int __cdecl NS::NS<int>::SN(void)'::`2'::SN
[MS Demangler] Demangle symbols in function scopes. There are a couple of issues you run into when you start getting into more complex names, especially with regards to function local statics. When you've got something like: int x() { static int n = 0; return n; } Then this needs to demangle to something like int `int __cdecl x()'::`1'::n The nested mangled symbols (e.g. `int __cdecl x()` in the above example) also share state with regards to back-referencing, so we need to be able to re-use the demangler in the middle of demangling a symbol while sharing back-ref state. To make matters more complicated, there are a lot of ambiguities when demangling a symbol's qualified name, because a function local scope pattern (usually something like `?1??name?`) looks suspiciously like many other possible things that can occur, such as `?1` meaning the second back-ref and disambiguating these cases is rather interesting. The `?1?` in a local scope pattern is actually a special case of the more general pattern of `? + <encoded number> + ?`, where "encoded number" can itself have embedded `@` symbols, which is a common delimeter in mangled names. So we have to take care during the disambiguation, which is the reason for the overly complicated `isLocalScopePattern` function in this patch. I've added some pretty obnoxious tests to exercise all of this, which exposed several other problems related to back-referencing, so those are fixed here as well. Finally, I've uncommented some tests that were previously marked as `FIXME`, since now these work. Differential Revision: https://reviews.llvm.org/D49965 llvm-svn: 338226
2018-07-30 05:12:34 +02:00
?NS@?1??SN@?$NS@H@10@QEAAHXZ@4HA
[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: int `public: int __cdecl NS::SN::NS<int>::SN(void)'::`2'::NS
[MS Demangler] Demangle symbols in function scopes. There are a couple of issues you run into when you start getting into more complex names, especially with regards to function local statics. When you've got something like: int x() { static int n = 0; return n; } Then this needs to demangle to something like int `int __cdecl x()'::`1'::n The nested mangled symbols (e.g. `int __cdecl x()` in the above example) also share state with regards to back-referencing, so we need to be able to re-use the demangler in the middle of demangling a symbol while sharing back-ref state. To make matters more complicated, there are a lot of ambiguities when demangling a symbol's qualified name, because a function local scope pattern (usually something like `?1??name?`) looks suspiciously like many other possible things that can occur, such as `?1` meaning the second back-ref and disambiguating these cases is rather interesting. The `?1?` in a local scope pattern is actually a special case of the more general pattern of `? + <encoded number> + ?`, where "encoded number" can itself have embedded `@` symbols, which is a common delimeter in mangled names. So we have to take care during the disambiguation, which is the reason for the overly complicated `isLocalScopePattern` function in this patch. I've added some pretty obnoxious tests to exercise all of this, which exposed several other problems related to back-referencing, so those are fixed here as well. Finally, I've uncommented some tests that were previously marked as `FIXME`, since now these work. Differential Revision: https://reviews.llvm.org/D49965 llvm-svn: 338226
2018-07-30 05:12:34 +02:00
?SN@?1??0?$NS@H@0NS@@QEAAHXZ@4HA
[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: int `public: int __cdecl NS::SN::NS<int>::SN(void)'::`2'::SN
[MS Demangler] Demangle symbols in function scopes. There are a couple of issues you run into when you start getting into more complex names, especially with regards to function local statics. When you've got something like: int x() { static int n = 0; return n; } Then this needs to demangle to something like int `int __cdecl x()'::`1'::n The nested mangled symbols (e.g. `int __cdecl x()` in the above example) also share state with regards to back-referencing, so we need to be able to re-use the demangler in the middle of demangling a symbol while sharing back-ref state. To make matters more complicated, there are a lot of ambiguities when demangling a symbol's qualified name, because a function local scope pattern (usually something like `?1??name?`) looks suspiciously like many other possible things that can occur, such as `?1` meaning the second back-ref and disambiguating these cases is rather interesting. The `?1?` in a local scope pattern is actually a special case of the more general pattern of `? + <encoded number> + ?`, where "encoded number" can itself have embedded `@` symbols, which is a common delimeter in mangled names. So we have to take care during the disambiguation, which is the reason for the overly complicated `isLocalScopePattern` function in this patch. I've added some pretty obnoxious tests to exercise all of this, which exposed several other problems related to back-referencing, so those are fixed here as well. Finally, I've uncommented some tests that were previously marked as `FIXME`, since now these work. Differential Revision: https://reviews.llvm.org/D49965 llvm-svn: 338226
2018-07-30 05:12:34 +02:00
; Make sure instantiated templates participate in back-referencing.
; In the next 3 examples there should be 3 back-references:
; 0 = X (right most name)
; 1 = C<int> (second from right)
; 2 = C (third from right)
; Make sure all 3 work as expected by having the 4th component take each value
; from 0-2 and confirming it is the right component.
?X@?$C@H@C@0@2HB
; CHECK: static int const X::C::C<int>::X
?X@?$C@H@C@1@2HB
; CHECK: static int const C<int>::C::C<int>::X
?X@?$C@H@C@2@2HB
; CHECK: static int const C::C::C<int>::X
; Putting everything together.
; namespace A { namespace B { namespace C { namespace B { namespace C {
; template<typename T>
; struct C {
; int B() {
; static C<int> C;
; static int B = 7;
; static int A = 7;
; return C.B() + B + A;
; }
; };
; } } } } }
?C@?1??B@?$C@H@0101A@@QEAAHXZ@4U201013@A
[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: struct A::B::C::B::C::C<int> `public: int __cdecl A::B::C::B::C::C<int>::B(void)'::`2'::C
[MS Demangler] Demangle symbols in function scopes. There are a couple of issues you run into when you start getting into more complex names, especially with regards to function local statics. When you've got something like: int x() { static int n = 0; return n; } Then this needs to demangle to something like int `int __cdecl x()'::`1'::n The nested mangled symbols (e.g. `int __cdecl x()` in the above example) also share state with regards to back-referencing, so we need to be able to re-use the demangler in the middle of demangling a symbol while sharing back-ref state. To make matters more complicated, there are a lot of ambiguities when demangling a symbol's qualified name, because a function local scope pattern (usually something like `?1??name?`) looks suspiciously like many other possible things that can occur, such as `?1` meaning the second back-ref and disambiguating these cases is rather interesting. The `?1?` in a local scope pattern is actually a special case of the more general pattern of `? + <encoded number> + ?`, where "encoded number" can itself have embedded `@` symbols, which is a common delimeter in mangled names. So we have to take care during the disambiguation, which is the reason for the overly complicated `isLocalScopePattern` function in this patch. I've added some pretty obnoxious tests to exercise all of this, which exposed several other problems related to back-referencing, so those are fixed here as well. Finally, I've uncommented some tests that were previously marked as `FIXME`, since now these work. Differential Revision: https://reviews.llvm.org/D49965 llvm-svn: 338226
2018-07-30 05:12:34 +02:00
?B@?1??0?$C@H@C@020A@@QEAAHXZ@4HA
[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: int `public: int __cdecl A::B::C::B::C::C<int>::B(void)'::`2'::B
[MS Demangler] Demangle symbols in function scopes. There are a couple of issues you run into when you start getting into more complex names, especially with regards to function local statics. When you've got something like: int x() { static int n = 0; return n; } Then this needs to demangle to something like int `int __cdecl x()'::`1'::n The nested mangled symbols (e.g. `int __cdecl x()` in the above example) also share state with regards to back-referencing, so we need to be able to re-use the demangler in the middle of demangling a symbol while sharing back-ref state. To make matters more complicated, there are a lot of ambiguities when demangling a symbol's qualified name, because a function local scope pattern (usually something like `?1??name?`) looks suspiciously like many other possible things that can occur, such as `?1` meaning the second back-ref and disambiguating these cases is rather interesting. The `?1?` in a local scope pattern is actually a special case of the more general pattern of `? + <encoded number> + ?`, where "encoded number" can itself have embedded `@` symbols, which is a common delimeter in mangled names. So we have to take care during the disambiguation, which is the reason for the overly complicated `isLocalScopePattern` function in this patch. I've added some pretty obnoxious tests to exercise all of this, which exposed several other problems related to back-referencing, so those are fixed here as well. Finally, I've uncommented some tests that were previously marked as `FIXME`, since now these work. Differential Revision: https://reviews.llvm.org/D49965 llvm-svn: 338226
2018-07-30 05:12:34 +02:00
?A@?1??B@?$C@H@C@1310@QEAAHXZ@4HA
[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: int `public: int __cdecl A::B::C::B::C::C<int>::B(void)'::`2'::A
llvm-undname: Tweak arena allocator - Make `allocUnalignedBuffer` look more like `allocArray` and `alloc`. No behavior change. - Change `Head->Used < Head->Capacity` to `Head->Used <= Head->Capacity` in `allocArray` and `alloc`. No intended behavior change, might be a minuscule memory usage improvement. Noticed this since it was the logic used in `allocUnalignedBuffer`. - Don't let `allocArray` alloc too small buffers for names that have more than 512 levels of nesting (in 64-bit builds). Fixes a heap buffer overflow found by oss-fuzz. Differential Revision: https://reviews.llvm.org/D60774 llvm-svn: 358489
2019-04-16 15:52:30 +02:00
?a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@a@@3HA
; CHECK: int a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a::a
Reference in New Issue Copy Permalink