GSOC Projects

Hey, I am Swapnil Raj I am student in Trinity College Dublin and I am interested
in working on LLVM. I am really interested in two projects listed, the first
one is the extending the clang AST with template information and the second is
finding smart null pointer dereferences. I am passionate about compilers and
interpreters, I have written a few small language based on lambda calculus. I am
currently writing a lazy functional language and visualizing its execution to
explain laziness for my undergraduate dissertation. I have also played with some industry-level interpreters
in the past namely V8 and CPython.

I believe I have good C++ experience, I have used it for my past two
internships where I worked on Google Chrome and Broadcom-switches respectively.

I have been grokking the LLVM source for a while and would like to get in touch
with the mentors to learn more about the projects and contribute to them.

Hi Swapnil,

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.
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
to me last year. This is a good resource:
Also for the second, probably this:


Στις Δευ, 16 Μαρ 2020 στις 2:42 μ.μ., ο/η Swapnil Raj via llvm-dev <> έγραψε:

Hi Swapnil,

If you are interested in the Static Analyzer project I recommend you to read through this discussion on cfe-dev:


Hi Swapnil,

Thanks for your interest in GSoC!

As for the "Extend clang AST to provide information for the type as written in template instantiations", the ClassTemplateSpecializationDecl represents the canonicalized
result of forming the specialization, so

using Foo = int;
vector<Foo> x;
vector<int> y;
auto v = x.begin();

... 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.

For example, when we form the "x.begin" expression in the above example (in BuildMemberReferenceExpr or somewhere near there), we

* take the type T1 of 'x':
`-TemplateSpecializationType 0xdafa140 'vector<Foo>' sugar vector
>-TemplateArgument type 'Foo':'int'
`-RecordType 0xdafa120 'vector<int>'
`-ClassTemplateSpecialization 0xdafa040 'vector'

* take the type T2 of 'begin':
`-FunctionProtoType 0xdb287b0 'vector<int,
allocator<int>>::iterator ()' cdecl
`-RecordType 0xdb28780 'vector<int, allocator<int>>::iterator'
`-CXXRecord 0xdafa428 'iterator'

* 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

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.)

Likewise, for x.front(), where the type of 'front' is something like:

 \`\-FunctionProtoType 0xdb3a0b0 &#39;vector&lt;int, allocator&lt;int&gt;

> ::value_type ()' cdecl
`-TypedefType 0xdb3a060 'vector<int, allocator<int> >::value_type' sugar
>-TypeAlias 0xdb39e38 'value_type'
`-SubstTemplateTypeParmType 0xdb39910 'int' sugar
>-TemplateTypeParmType 0xdb09a80 'T' dependent depth 0 index 0
> `-TemplateTypeParm 0xdb09a38 'T'
`-BuiltinType 0xdacd950 'int'

... 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.

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).

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.

In the meantime, could you send Richard and me your CV?

Best, Vassil

PS: Thanks Stefanos for cc-ing us!