Re: cfe-dev Digest, Vol 164, Issue 59

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: cfe-dev Digest, Vol 164, Issue 59

Manas via cfe-dev
Message 3:
Re: Clang integration to other tools
(Andi-Bogdan Postelnicu via cfe-dev)
I would use the .clang-format file in tools like:
- Texas Instruments Code Composer 
- Eclipse 
- ARM Keil 
Running it in Texas Instruments Code Composer is the priority for now.
In doing so, I would like to find out what options are available to run the clang format. This also under Windows.
Being new to this, I don't even know how to bring the .clang-format file into Texas Instruments Code Composer. 
And further, how do I get C files into Clang? 
I am sending you my .clang-format file in the attachment. 
Shirley :) 
Gesendet: Mittwoch, 17. Februar 2021 um 16:07 Uhr
Von: "via cfe-dev" <[hidden email]>
An: [hidden email]
Betreff: cfe-dev Digest, Vol 164, Issue 59
Send cfe-dev mailing list submissions to
[hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
[hidden email]

You can reach the person managing the list at
[hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cfe-dev digest..."

Today's Topics:

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)


Message: 1
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 ( 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:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>


Message: 2
Date: Wed, 17 Feb 2021 10:25:46 +0100
From: shirley breuer via cfe-dev <[hidden email]>
To: [hidden email]
Subject: [cfe-dev] Clang integration to other tools

Content-Type: text/plain; charset="utf-8"

An HTML attachment was scrubbed...
URL: <>


Message: 3
Date: Wed, 17 Feb 2021 11:30:29 +0200
From: Andi-Bogdan Postelnicu via cfe-dev <[hidden email]>
To: shirley breuer <[hidden email]>
Cc: [hidden email]
Subject: Re: [cfe-dev] Clang integration to other tools
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"


What tools are you trying to use with .clang ?


> On 17 Feb 2021, at 11:25, shirley breuer via cfe-dev <[hidden email]> wrote:
> I have created a file in .clang format and now I want to try to integrate it with different tools under Windows.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>


Message: 4
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 <> 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 plan

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.

Next steps

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

* <> implements round-tripping,
* <> manually generates complex CodeGenOptions,
* <> changes the round-trip to handle whole CompilerInvocation at once instead of handling individual members separately.

Does the proposed plan of enabling round-trip in assert builds sound good?

Jan Svoboda


Message: 5
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?



Subject: Digest Footer

cfe-dev mailing list
[hidden email]


End of cfe-dev Digest, Vol 164, Issue 59

cfe-dev mailing list
[hidden email]

clang-format (1) (1K) Download Attachment