When replying, please edit your Subject line so it is more specific
than "Re: Contents of cfe-dev digest..."
1. Outreachy - Mentors and projects needed
(Tanya Lattner via cfe-dev)
2. Clang integration to other tools (shirley breuer via cfe-dev)
3. Re: Clang integration to other tools
(Andi-Bogdan Postelnicu via cfe-dev)
4. Update on generating cc1 command line from CompilerInvocation
(Jan Svoboda via cfe-dev)
5. CLang. How to turn on reference to pointer errors
(Andrey Sharoyko via cfe-dev)
Date: Tue, 16 Feb 2021 14:40:38 -0800
From: Tanya Lattner via cfe-dev <[hidden email]>
To: cfe-dev <[hidden email]>
Subject: [cfe-dev] Outreachy - Mentors and projects needed
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"
Outreachy (https://www.outreachy.org) is an internship program with a goal to increase diversity in open source. Internships are 3 months long (end of May to end of August), remote, and pay a stipend. Interns work with experienced mentors from open source communities, such as LLVM. Outreachy projects may include "programming, user experience, documentation, illustration, graphical design, data science, project marketing, user advocacy, or community event planning.” Outreachy invites the following applicants (quoting from their website):
"Outreachy expressly invites women (both cis and trans), trans men, and genderqueer people to apply. We also expressly invite applications from residents and nationals of the United States of any gender who are Black/African American, Hispanic/Latinx, Native American/American Indian, Alaska Native, Native Hawaiian, or Pacific Islander.
Anyone who faces under-representation, systemic bias, or discrimination in the technology industry of their country is invited to apply."
The LLVM Foundation will sponsor one or more internships through Outreachy and we are looking for mentors with project ideas. If you are interested in being a mentor, please send me an email. The timeline is a little tight as the deadline for mentors to submit project proposals is March 7th. We will need at least 2 mentors. Mentor responsibilities are detailed here: https://www.outreachy.org/mentor/#mentor
As many of you know, we have long participated in Google Summer of Code (GSOC) and had great success with the program. We will continue to participate with GSOC and this is not a replacement. Participation in Outreachy is another way to reach more contributors to LLVM. It also aligns with the LLVM Foundation’s program to increase diversity and inclusion within the LLVM project and the field of compilers and tools (https://community-dot-o.llvm.org). Additionally, this is an opportunity for longer projects that no longer meet the criteria for GSOC to find an intern. GSOC recently modified their rules and decreased project length to 175 hours over 10 weeks, while Outreachy remains at 360-480 hours over a 12 week period.
I hope you will consider being a mentor! If you have any questions, please let me know.
Date: Wed, 17 Feb 2021 15:01:53 +0100
From: Jan Svoboda via cfe-dev <[hidden email]>
To: David Blaikie via cfe-dev <[hidden email]>
Subject: [cfe-dev] Update on generating cc1 command line from
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8
Hi, I work on explicitly building Clang modules via pre-scanning at Apple along with Michael Spencer and Duncan Exon Smith.
As part of our effort, Daniel Grumberg posted an RFC to Generate CC1 Command Lines from a CompilerInvocation instance <https://lists.llvm.org/pipermail/cfe-dev/2020-May/065421.html> some time ago, which got some positive feedback. The implementation is almost complete and we want to check if everyone is okay with our direction.
The RFC proposed the following steps:
1. Build an infrastructure for automatic command line option marshalling.
2. Use the infrastructure to automatically parse and generate simple options.
3. Manually implement code for generating non-trivial options.
4. Turn on round-tripping in assert builds to ensure correctness.
Steps 1, 2 are already finished and upstream, step 3 is almost done.
Round-tripping in step 4 means that CompilerInvocation::CreateFromArgs does not create the instance directly from the original command line. Instead, it parses the arguments into a dummy CompilerInvocation instance and uses it to generate new command line. The real CompilerInvocation is then parsed from the generated command line. When exercised by Clang’s test suite, this setup validates the generated command line has semantics identical to the original.
Currently, round-tripping can be enabled by building Clang with -DCLANG_ROUND_TRIP_CC1_ARGS=ON or by invoking cc1 with -round-trip-args. The generated command line can be printed by using the -Rround-trip-cc1-args option.
After all patches are upstream and the whole CompilerInvocation is serializable, it would be good to enable round-tripping by default for assert builds. This would ensure bots building with assertions fail whenever new cc1 option is not being generated correctly. The process of adding new command line option and using the marshalling infrastructure is documented in the Clang Internals Manual <https://clang.llvm.org/docs/InternalsManual.html#adding-new-command-line-option>. I’d be watching patches related to command line options for a while and helping folks with implementing generation for new options.
Special considerations for downstream
Downstream projects that need to adopt this feature in their own timeframe could temporarily disable round-tripping by building with -DCLANG_ROUND_TRIP_CC1_ARGS=OFF or always passing -no-round-trip-args to cc1.
Below is a non-exhaustive list of related patches:
Does the proposed plan of enabling round-trip in assert builds sound good?
Date: Wed, 17 Feb 2021 18:02:20 +0300
From: Andrey Sharoyko via cfe-dev <[hidden email]>
To: [hidden email]
Subject: [cfe-dev] CLang. How to turn on reference to pointer errors
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=us-ascii
In XCode I declare a function
void func (const Valu & val);
And when I mistakenly pass a pointer instead of a reference to an object, the compiler does not issue an error or warning message. But it generates incorrect code.
How do I enable this error or warning message?