<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hi Swapnil,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"> Thanks for your interest in GSoC!</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"> As for the "Extend clang AST to
provide information for the type as written in template
instantiations", the ClassTemplateSpecializationDecl represents
the canonicalized<br>
result of forming the specialization, so<br>
<br>
using Foo = int;<br>
vector<Foo> x;<br>
vector<int> y;<br>
auto v = x.begin();<br>
<br>
... will result in x and y denoting the same
ClassTemplateSpecializationDecl. It doesn't make sense for that
declaration to track the sugared type, because that declaration is
used for accesses with different sugar. The type sugar should not
ever affect the behavior of the instantiation, so should not be
part of the instantiation. Rather, it's part of the way that the
instantiation is named, so should be part of that naming context.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">For example, when we form the "x.begin"
expression in the above example (in BuildMemberReferenceExpr or
somewhere near there), we<br>
could:<br>
<br>
* take the type T1 of 'x':<br>
`-TemplateSpecializationType 0xdafa140 'vector<Foo>' sugar
vector<br>
|-TemplateArgument type 'Foo':'int'<br>
`-RecordType 0xdafa120 'vector<int>'<br>
`-ClassTemplateSpecialization 0xdafa040 'vector'<br>
<br>
* take the type T2 of 'begin':<br>
`-FunctionProtoType 0xdb287b0 'vector<int,<br>
allocator<int>>::iterator ()' cdecl<br>
`-RecordType 0xdb28780 'vector<int,
allocator<int>>::iterator'<br>
`-CXXRecord 0xdafa428 'iterator'<br>
<br>
* form a new type sugar node (say, MemberSugarType) that tracks
T1 and T2, and has the same canonical type as T2, but that has
custom desugaring logic to allow it to produce a more friendly
type name<br>
<br>
In this case, desguaring a MemberSugarType wrapped around a
FunctionProtoType would push the member sugar onto the return type
and parameter types of the type; desugaring a MemberSugarType
wrapped around a RecordType representing a member of the type
tracked by a MemberSugarType would form an ElaboratedType
describing the name of that member as a member of the sugared
type. So we'd end up with the type of "x.begin" desugaring to
vector<Foo>::iterator(), as desired. (When we grab the
return type of a function in a function call, we'll need to be
careful to single-step desugar it until we reach a function type,
to move the sugar onto the return type. And likewise in other
places too.)<br>
<br>
Likewise, for x.front(), where the type of 'front' is something
like:<br>
<br>
`-FunctionProtoType 0xdb3a0b0 'vector<int,
allocator<int><br>
> ::value_type ()' cdecl<br>
`-TypedefType 0xdb3a060 'vector<int, allocator<int>
>::value_type' sugar<br>
|-TypeAlias 0xdb39e38 'value_type'<br>
`-SubstTemplateTypeParmType 0xdb39910 'int' sugar<br>
|-TemplateTypeParmType 0xdb09a80 'T' dependent depth 0
index 0<br>
| `-TemplateTypeParm 0xdb09a38 'T'<br>
`-BuiltinType 0xdacd950 'int'<br>
<br>
... we'd wrap that in a MemberSugarType, and desugaring the
wrapped function type would produce a function type whose
parameter and return types are wrapped. But then we can do
something more: once we get to a MemberSugarType wrapped around a
SubstTemplateTypeParmType, we can desugar that type to "Foo"
(taking the type sugar for the template argument from the
TemplateSpecializationType). So we can desugar the type of a call
to x.front() to Foo.<br>
<br>
You'd need to work out exactly what kinds of sugar type nodes to
add, and which information it makes sense to track in the sugar
type. For instance, it might make sense for the sugar type that we
use for a class member access to track whether the member was
found in the type of the object expression (the expression to the
left of the . or ->), or if it was found in a base class (and
if so, which one).</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">This information was provided a last
year GSoC candidate by Richard Smith. It should contain enough
hints for you to assess if that's something interesting to do this
summer.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">In the meantime, could you send Richard
and me your CV?</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Best, Vassil<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">PS: Thanks Stefanos for cc-ing us!<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 3/17/20 1:22 AM, Stefanos Baziotis
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CABAxE=Kn0uCYiS4rav=Ji=LxsNipouUnchhTz+aUPZ00-FniPg@mail.gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div dir="ltr"> Hi Swapnil,<br>
<br>
I added the mentors of the 2 projects you mentioned. Actually, I
couldn't find the e-mail address of Artem Dergachev, but I hope
the rest will help you.<br>
One note is that I see more success when students have one
thread per gsoc project. Second, the first of the 2 projects was
interesting<br>
to me last year. This is a good resource: <a
href="https://www.youtube.com/watch?v=VqCkCDFLSsc"
moz-do-not-send="true">https://www.youtube.com/watch?v=VqCkCDFLSsc</a><br>
Also for the second, probably this: <a
href="https://www.youtube.com/watch?v=g0Mqx1niUi0"
moz-do-not-send="true">https://www.youtube.com/watch?v=g0Mqx1niUi0</a><br>
<br>
Best,<br>
Stefanos</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Στις Δευ, 16 Μαρ 2020 στις
2:42 μ.μ., ο/η Swapnil Raj via llvm-dev <<a
href="mailto:llvm-dev@lists.llvm.org" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
έγραψε:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey,
I am Swapnil Raj I am student in Trinity College Dublin and I
am interested<br>
in working on LLVM. I am really interested in two projects
listed, the first<br>
one is the extending the clang AST with template information
and the second is<br>
finding smart null pointer dereferences. I am passionate about
compilers and<br>
interpreters, I have written a few small language based on
lambda calculus. I am<br>
currently writing a lazy functional language and visualizing
its execution to<br>
explain laziness for my undergraduate dissertation. I have
also played with some industry-level interpreters<br>
in the past namely V8 and CPython.<br>
<br>
I believe I have good C++ experience, I have used it for my
past two<br>
internships where I worked on Google Chrome and
Broadcom-switches respectively.<br>
<br>
I have been grokking the LLVM source for a while and would
like to get in touch<br>
with the mentors to learn more about the projects and
contribute to them.<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
<a
href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>