Historical Clang Language WG Meeting Minutes (Jun 2025-Sep 2025)

Clang Frontend
1

Meeting Agenda - September 17th, 2025
Agenda

  • Shafik: Core Working Group Telecons started up again, we will have three more meeting before Kona.
    • Main goal is to get in front of NB comments
  • Vlad: WG14 meeting happened on Aug 25–29
    • WG14 is still working on how to determine consensus, so the poll results may be surprising to some
    • N3433 Forward declarations of parameters
      • 13 / 14 / 4 ­– no consensus, not adopted
      • Authors claim that Clang opposition lacks technical arguments
      • There is also a separate Apple proposal
      • N3433 is refinement of Martin’s proposal, to use forward declared parameters
    • N3490 embed synchronization, r1
      • No polls taken. Needs another revision
      • This paper is about core issues looked at at the end of Sophia
      • Author said additional changes are needed, so no poll taken
    • N3568 Adding struct enum
      • Two direction polls taken: 14 / 5 / 7 for more C++ compatibility, 9 / 8 / 12 for the direction presented the paper (using member access operator)
      • There was a lot of feedback on the paper
      • Proposed scoped enums but not w/ the same rules as C++ and would be incompatible with C++
      • Committee was amenable to using ::
      • Hubert would prefer they make it a single token like in C++
    • N3557 Function call without decay
      • Proponents highlighted that they do not ask this to be adopted as a DR, as if it would help
      • 13 / 6 / 9 – no strong consensus, not adopted
      • Pointed out that tooling won’t be happy with this change
      • Corentin pointed out that there is no implementation and we really need an implementation
      • Corentin is not too worried about tooling since we don’t make promises about AST matchers
      • Vald: it would helpful if the paper discussed the transition process from the compiler perspective
    • N3589 Defer TS
      • I think the editor said that this needs another revision
      • No polls were taken
      • Author said another revision is needed
    • N3532 Member access of an incomplete object
      • Adopted by unanimous consent
      • Accepted to require complete types on the left side of the dot
      • Mostly wording bug fix, should not break any existing code
    • N3658 Simplified lexical scope for labels
      • Positive feedback from Ambrose swayed some votes
      • 18 / 7 / 1 — support for direction of the paper
      • Hubert asked since this seems like it has some C++ implication if at least the liaison group looked at it
    • N3629 Adopt qualifier conversion rules from C++
      • Seems to be a simplified version of [conv.qual]
      • 23 / 0 / 6 – strong consensus, adopted
      • Consistency w/ C++
    • N3582 Generalized function calls (TS 25007)
      • Consists of the following:
        • “Calling convention specifier” _Call_as(n), which generalizes calling convention specifiers: _Call_as (1) void f1 (void);
        • Extension to designated initializers syntax that specifies where to copy values from for data members that don’t have their designated initializers: Point3D p2 = { p1; .y = 6 };
          • Implications for C++
        • Simplified lambdas without closure types that borrow C++ syntax
        • _Recur function designator, which is useful in the same cases as func, but does work with unnamed functions like lambdas above
        • return goto, a tail call elimination facility, “fundamentally similar” to Clang’s musttail. It’s well-formed only when tail call elimination can be done, and can be made ill-formed for any implementation-defined reason.
      • 12 / 13 / 3 — weak consensus in favor of submitting to SC22
      • Corentin asks if anyone is implementing any of TS’s coming out of WG14
      • Ambrose said he has an implementation of defer
      • Hubert is not too concerned about the designated init extension
    • Next Wg14 meeting will be virtual
  • RFC from Infra Team requiring PRs for all commits
    • Negative feedback from Erich and Vlad
    • Seems to contradict the promises from when we transitioned two years ago
    • Proposed to enable some additional github functionality, especially it seems this will help release managers
    • Vlad: feels this is weak motivation and worries this will lead to required review for PRs when we are already quite short on reviewers

Round Table

Meeting Agenda - September 3rd, 2025
Agenda

  • Shafik: const integer variables and uncaught_exception. Core discussion starts here: https://lists.isocpp.org/core/2025/08/18460.php
    • There is talk about depreciating this feature
    • Shafik: constant variables are usable in constant expressions, and they interact poorly with uncaught_exception. People consider deprecating usability of constant variables in constant expressions. Shafik pushed back, because it’s really easy to run into this. Diagnostic is going to be very noisy, everyone relies on this. Richard kind of agreed. EWG should’ve caught this. We either should remove constexpr specifier from those functions, or do something else. Discussion died after this
    • Vlad: this topic was brought up in WG14 meeting. Result seem to be the same as the one Shafik advocates for
    • Shafik: I was hoping Hubert would be here
    • Corentin: if we don’t make uncaught_exception constexpr, no one will notice
    • Shafik: agree. Core is not the right place to fix design mistakes, so paper is due
    • Hubert is here
    • Shafik: have you been following the discussion?
    • Hubert: I haven’t. We have a telecon coming; is this an NB comment?
    • Shafik: yes, NB comment has been filed
    • Hubert: then I’m not worried, because we have procedural grounds to discuss
  • Vlad: Clang 21 released on Aug 26 (Discourse)
    • Shafik: there was a big openmp regression, but it was fixed right away
    • Corentin: I wish we did a better job communicating when release comes out. We had an ABI issue with pointer authentication
    • Shafik: agreed. Not sure who to talk to
    • Corentin: I think Tobias and Tom Stellard
    • Vlad: yes, those are the right people
    • Corentin: we should have a schedule and stick to it
    • Vlad: there was a long discussion just before 21 release cycle began
    • Reid: if we’re concerned, should we block releases over ABI?
    • Corentin: the issue was that if we did something in Clang 20 instead of 21, a type trait would change its behavior
    • Reid: rather than being surprised by the release process, we should enable ABI changes when they are ready irrespective of release process
    • Vlad: we need to be aware of the schedule to fix stuff
    • Shafik: this is useful for people to feel the time pressure
    • Reid: what was surprising?
    • Corentin: when we started, we expected 4 RCs, but the third one was shipped
    • Reid: I see
    • Corentin: there was an expectation that there is two more weeks
    • [ Hubert joined and requested clarification/more context ]
    • Hubert: What is the ABI issue?
    • Corentin: it’s about pointer auth on arm64, I need to check with Olivier
    • Hubert: I’m not following the minutes
    • Shafik: Corentin, can you add the link?
    • Corentin: sure
  • On the forums:
    • Aaron Ballman is away until early October (post)
      • Shafik: hopefully he’s having a good time. I’ll be running this meeting in his absence
    • New subcategory under Clang Frontend: ISO WG14/WG21
      • Reid: I raised this. Is this useful? I recall Aaron saying that it would be useful to have a clear communication channel to the committee on what the community thinks. It seems useful. Aaron wanted write-ups on proposals, so that we can bring this to the meetings.
      • Corentin: it’s useful if this is a place where we decide what our opinion on. It won’t be useful if it becomes a place for design discussions. If you saw the discussion on forward declared parameters, people were repeating the same argument
      • Reid: CAT definitely suffered from the communication fragmentation
      • Corentin: the same sort of discussion happen on GCC bug tracker
      • Reid: how do we capture the intent that this is a place for clang implementation opinion?
      • Corentin: update the description
      • Reid: do you want to take it as an action item?
      • Corentin: yes
      • Shafik: I wonder if discourse is the right place, because it’s too broad
      • Reid: Do you feel it’s valuable?
      • Shafik: those discussions have been already happening, we just need more of that. Most of the productive discussions happened in more private environments. Sometimes several maintaners write their position in a google doc, and then come with it to public places. Not sure if it worked well. I understand your desire to have a place for discussions
      • Reid: google doc process is very normal and natural, but at the end of the process it’s useful to have something linkable
      • Corentin: we don’t want to gatekeep the discussion, but we need implementer’s opinions, not user’s opinions
      • Reid: I tried to create a tool to say no. if we keep copying google docs into discourse, that’s a win
      • Corentin: we need to remain transparent
    • Usage of AI transcripts (link)
      • Shafik: some people are supportive, some are pushing back. There is a difference between helping the scribe and the full transcript. Someone else pushed back on the accuracy.
      • Vlad: we should have an opinion
      • Corentin: this should be a community-wide policy
      • Reid: I’m not sure that we have an single opinion, and it’s going to be hard to establish the single policy, like we have different CI between clang and libc++
      • Shafik: makes sense
    • Policy on supporting newer C++ standard in LLVM codebase (link)
      • Shafik: I mentioned on the thread that this is not free lunch. There was an issue with a PR that helps with C++23.
      • Ambrose: is this about headers or the entire codebase?
      • Vlad: the entire codebase
      • Ambrose: headers are easier to support
      • Corentin: do we have CI?
      • Shafik: this was brought up
      • Reid: this is another buildbot configuration. I’m concerned with the risk of having headers compiled in different language mode
      • Vlad: we might want to accept patches instead of promising support. C++23 issues are very real, because of constexpr unique_ptr
      • Corentin: do we support C++20 for build mode?
      • Vlad: I think yes, we have godbolt
      • Reid: I don’t know, but google relies on it
      • Shafik: PR which started the discussion: https://github.com/llvm/llvm-project/pull/154372
      • Reid: we need to tackle standards separately
  • Vlad: LLVM Qualification WG meeting on Sep 2
    • The topic of clang conformance is still a major topic but it does not look like we have a path to forward progress at this point.
    • There does not seem to be full understanding of the scope of the work required to do this well.
    • Various comments that we have a lot of testing and we are not close to full coverage and opinions seems to express doubt we can do this without extraordinary amount of work.
  • Maria: embed support for C++
    • Mariya wants to understand the C++ side of changes to embed so she can finish up work for support
    • Vlad was saying that most of the issue have been closed at this point and we should be able to proceed using the C++ wording for both C and C++
    • Shafik: asked Mariya if this feedback is sufficient
    • Mariya: Will start with checking the C++ issues resolutions
    • Hubert: there is specific points where and C and C++ diverge and that is on purpose, he thinks
    • Vlad: … identifiers with underscores …
    • Corentin suggested to accept the underscore forms in C++ mode as an extension (with no diagnostics whatsoever)
  • Vlad: WG14 meeting happened on Aug 25–29
    • N3433 Forward declarations of parameters
      • 13 / 14 / 4 ­– no consensus, not adopted
    • N3490 embed synchronization, r1
      • No polls taken. Needs another revision
    • N3568 Adding struct enum
      • Two direction polls taken: 14 / 5 / 7 for more C++ compatibility, 9 / 8 / 12 for the direction presented the paper (using member access operator)
    • N3557 Function call without decay
      • Proponents highlighted that they do not ask this to be adopted as a DR, as if it would help
      • 13 / 6 / 9 – no strong consensus, not adopted
    • N3589 Defer TS
      • It seems that no polls were taken
    • N3532 Member access of an incomplete object
      • Adopted, seemingly by unanimous consent
    • N3658 Simplified lexical scope for labels
      • Positive feedback from Ambrose swayed some votes
      • Not sure if it was adopted, but probably was
    • N3629 Adopt qualifier conversion rules from C++
      • Seems to be a simplified version of [conv.qual]
      • I believe this was adopted
    • N3582 Generalized function calls (TS 25007)
      • Consists of the following:
        • “Calling convention specifier” _Call_as(n), which generalizes calling convention specifiers: _Call_as (1) void f1 (void);
        • Extension to designated initializers syntax that specifies where to copy values from for data members that don’t have their designated initializers: Point3D p2 = { p1; .y = 6 };
        • Simplified lambdas without closure types that borrow C++ syntax
        • _Recur function designator, which is useful in the same cases as func, but does work with unnamed functions like lambdas above
        • return goto, a tail call elimination facility, “fundamentally similar” to Clang’s musttail. It’s well-formed only when tail call elimination can be done, and can be made ill-formed for any implementation-defined reason.
      • 12 / 13 / 3 — weak consensus in favor of submitting to SC22

Meeting Agenda - August 20th, 2025
Agenda

  • Vlad: Clang’s C++ conformance was discussed in LLVM Qualification WG meeting on August 5th
    • Corentin: not convinced a commercial conformance test suite is not useful to us; they’re not interested in improving clang specifically. Qualification will basically tell us “we’re not conforming” but not much else.
    • Ariel: not sure I agree; we want these test suites to pass.
    • Corentin: if we don’t have access to the test case and cannot commit the test case, then what can we do?
    • Hubert: true, we’re going to hear we’re not conforming. And I’m not convinced we’re going to fix all of them.
    • Shafik: we’re maybe not going to fix all of them, but it’s still good to know how we’re non-conforming. It would be interesting to know if we’re all non-conforming in the same ways, too.
    • Ariel: there’s the linguistic aspect to conformance and the libraries as well. Confirming how the libraries behave is also helpful
    • Aaron: helpful for DR conformance, newer language features, etc
    • Corentin: we still want tests committed in the repo to help us find regressions
    • Shafik: depends on cadence; are the tests run continually or just every few months?
    • Aaron: I imagine continual and we can get deltas
    • Corentin: we still need to eventually get code into our test suite so we don’t regress, right?
    • Shafik, Hubert: generally agreed, needs to get into our suite
    • Hubert: whether or not we’re interpreting the standard in the way others agree with is an unknown without a conformance test suite. Similarly, if our feature tracking is incomplete, we don’t know that without third-party verification
    • Corentin: if we cannot look at their code, when something fails, what sort of feedback do we get?
    • Ariel: why don’t the standards bodies have these suites?
    • Aaron: due to competition
    • Ariel: is it possible to buy one of these companies? An industry consortium could buy them
    • Reid: this doesn’t feel like something we worried about five years ago; we had Richard who was project editor and he took care of conformance concerns. Now it seems like we’re worried?
    • Aaron: always been worried (C for example), but this because of safety critical qualification
    • Shafik: not having the source code is also a challenge when the suite identifies an issue with the standard; we can’t share it with Core.
    • Ariel: but it’s still useful information because it tells the committee there’s an issue.
    • Reid: llvm compile time tracker is a good example of putting data out there and then people start using it to do work. So putting failures out there may cause labor to show up and help with.
    • Corentin: if folks care about conformance, a company should hire people to do that work. But let’s assume we do all the conformance testing; how does that help qualifying Clang from a legal perspective? Can we self-qualify?
    • Aaron: it’s pretty typical for third-party verification as a checklist item
    • Corentin: we should document places where we know we’re not conforming because we have a reason to not conform (like ABI breaks).
  • WG14 meetings happening next week in Brno
    • Aaron will be attending in person, expects to see others there from the community as well (Yeoul, John McCall, Vlad, Corentin)
    • Aaron plans to vote: For the defer TS (Ambrose has volunteered to implement in Clang, GCC already has implementation efforts on it), Against or Abstain on the generalized function calls TS (depends on whether any implementation intends to implement it; if nobody volunteers, Aaron will vote No). Any disagreement?
    • If there are any papers folks want me to vote a particular way on, let’s talk about them now.
  • Meetings in Sept?
    • Aaron will be out, who wants to run the meetings?
    • Aaron will try to find a chair for Sept, if cannot find one by Fri then cancel Sept meetings, report back via Discourse.
    • If people have NB comments to make, they can be sent to a C++ committee member (Corentin, Hubert, etc).
    • Shafik agreed to chair the meetings while Aaron is out.
  • For general awareness (can be pulled up for discussion on request)
    • Hardening (RFC)
      • There was a discussion of this at the memory safety working group on Aug 7th
      • Aaron will be out, won’t work on this in Sept.
      • Need to keep gathering requirements
    • New text diagnostic format (RFC)
      • Discussion has died down, needs a decision?
      • Ambrose will keep working on it, but he’s still not perfectly happy with the current approach. He’s hoping to improve progressively, so we can gather feedback from users. But the current plan is for the new format to not be stable currently.
      • Reid: SARIF diagnostics format?
      • Ambrose: this is somewhat related, SARIF has the way to handle nested diagnostics and so we could make use of that now (currently we flatten everything in SARIF). There are some unimplemented things though, like with invalid source locations.
    • restrict support (RFC)
      • Likely heading towards consensus against
      • Still want something along these lines; Jeroen’s patch is still not ready
      • Rust folks are interested in improved alias analysis
    • CHERI upstreaming (RFC)
    • GitHub PR auto-merge feature (RFC)
    • libc++ want to take dependency on Boost.Math (RFC)
    • Driver option to select C standard library implementation (RFC)
    • Maintainer policy discussion (thread)
  • Round Table
    • Aaron:
      • mostly just prepping for WG14. otherwise will be out for Sept
    • Ambrose:
      • worked on the defer TS, only took a few hours to implement
      • working on named loops, been getting good reviews
      • code reviews otherwise
    • Ariel
      • Mostly been in frontend downstream
    • Corentin
      • Still trying to work on constraint satisfaction checking with Younan, making progress but still not done. Could use some help. Tests pass in Clang, but cannot compile libc++ (we must be lacking testing in Clang). A bunch of performance regressions as well.
      • Once we fix libc++, how to deploy without breaking everyone? Would helpful for downstreams to play with the patch when it’s closer to ready
      • Hubert: maybe Louis (Apple) has some ability to help there, at least for the libc++ deployment side of things
    • Hubert
      • -finput-charset work, using the override file contents in the source manager (takes the buffer not the file form), still need to check if we have some weird timing problem. But we’re currently getting weird source location behavior for diagnostics past the original buffer size. Hopefully it’s a timing issue that can be solved. Otherwise, we can maybe switch to using virtual files instead. This feature may have modules interactions for BMIs; I’ve not tried out modules enough to know what it means when the documentation expects “source stability”. What happens when you have the visibility of multiple versions of the same file due to paths, what’s the fallout? Is that a user error or a compiler problem?
      • Corentin: hopefully it would be ill-formed as part of the ODR violation checker for you to have multiple copies of a file with different encodings.
      • Hubert: ODR checking is optional currently, still needs to be checked
      • Hubert: I don’t know where we are on the plan for all standard library modules to be importable. Without a stable BMI format, I think we have to have the frontend do the precompiling if you want it to work out of the box in a conforming manner.
      • Corentin: I don’t think anyone knows right now, you should ask Michael Spencer. Someone is working on that kind of compilation in the driver. I don’t know how it will interact with encodings and I don’t think anyone has a design for that. This would require build system tool support, even for just the standard headers.

Meeting Agenda - August 6th, 2025
Agenda

  • Clang 21 release branch
    • Aaron: Release notes should be in good shape now
      • There was one release blocker. It’s fixed, but not yet cherry-picked in the release branch. It was PCH
      • Nothing else
      • Shafik: I can’t think of anything either
      • Aaron: if you see release blockers, tag me
      • Hubert: problem with the release notes. Posted a PR, but not sure how it gets merged
      • Corentin: sent me the link
      • Hubert: the reviewer was under impression it goes to main, but I think it goes to the release branch
      • Aaron: it’s always confusing when release branches are created
      • Aaron: I fixed 5-6 dropped release notes
      • Aaron: if you look at don’t see a release note you expect, let me know
      • Hubert: there was a mistake in 21.x release notes. I’ll send it to Corentin
      • Corentin: it is a draft. This is why I didn’t see it
      • Hubert: because last time release manager merged in an unfinished PR
      • Hubert: made it not a draft now
      • Corentin: fix in main. All good
      • Hubert: because main has nothing
      • Hubert: I’m hoping that patches in the queue are getting merged
      • Aaron: yes, release managers are merging them once a week
    • Aaron: PCH are not working in C23 mode
  • Aaron: Participation in the next 64-bit source location CAT meeting
    • Do we still want to hold that meeting?
    • Aaron: we only have 4 people responding to a doodle to pick the time for the meeting. Author is not able to make it. Do we still want to hold the meeting?
    • Corentin: people are on the vacation, so this is expected
    • Aaron: I’m not certain that the author will be available before October
    • Corentin: we’re not under pressure to fix it now anyway
    • Reid: I’d like to disagree a little bit. What are we doing now? It would be good to have feedback on RFC, because it’s not a one-way decision. There were concerns about having a CMake option, so I’d like to hear back from deployments.
    • Aaron: is there anything preventing Google from deploying it internally anyway?
    • Reid: the moment we deploy this internally, it’s one-way, and the pressure to resolve the issue will be off.
    • Reid: google will immediately depend on anything we deploy. We shouldn’t delay for tool long
    • Aaron: can we hold the meeting without Haojian?
    • Reid: I think we should try to hold it without him
    • Aaron: I ran into another issue with source locations. COUNTER can overflow, but it’s hidden by 32-bit source location space at the moment.
    • Reid: we’re worried about another downstream patch we’ll need to maintain
    • Hubert: there’s an RFC to have an option, but what is the risk that we move to it by default
    • Corentin: this is what we want to discuss in a meeting we are trying to schedule. This is why we need to hold it with all the stakeholders present before we move forward. I’d rather have 64-bit optimizations than the option to enable it, because it has a cost. If you don’t want to have a performance penalty at all, option is not going to give you that
    • Hubert: but it’s a compile-time CMake option
    • Corentin: our layout optimizations can’t take both into account at the same time
    • Reid: there is a possibility google comes back with a positive feedback
  • Aaron: Upcoming WG14 meeting
    • TS on defer: do we plan to implement?
    • TS on return goto/constexpr functions: do we plan to implement?
    • TS on _Optional: do we plan to implement?
    • Aaron: some of the TS are from the time when WG14 didn’t tell no to proposals. All of them are approved as a work items, but not yet voted on by the committee. JeanHeyd started a ballot on defer without asking Robert. The ballot was closed the next day
    • Corentin: this is an old story of us not implementing things because they are not in the standard
    • Aaron: but we implemented coroutines under a flag
    • Aaron: is any of these TSes is important enough we’re going to support it even if it fails in WG14
    • Corentin: if someone makes a PR, we’ll review it, but no one is going to prioritize TS over C23 feature
    • Aaron: well, we’re not going to review. _Optional is a good example. I’m looking for people who says definite yes to any of them.
    • Corentin: most people on the call work with C++, and defer is not useful to them. You should ask people who work with C
    • Aaron: Hubert? Ariel? IBM cares about C
    • Hubert: we work with stable things
    • Ariel: we care about printf
    • Aaron: defer proposal is almost like RAII
    • Hubert: for defer, the question is whether it fits into C’s response to a wider question to memory safety questions. If it does, then more people are interested
    • Aaron: my feeling is that defer is the one we are interested the most as a community. Resource allocation is where it shines. But then there’s alloca and VLAs, so there are additional edge cases introduced by this TS. I think I’m voting for it, abstain at worst. I was planning to implement it myself, until intel lost its workforce.
    • Corentin: if we were to implement it, and it changes afterwards, what do we do?
    • Aaron: we don’t promise stability
    • Aaron: it seems that GCC is going to implement it, too
    • Corentin: I’m fine reviewing it if it appears
    • Aaron: I’m don’t hear a strong support for it, but no one is against
    • Ariel: we by default oppose anything that requires additional runtime
    • Aaron: good to know
    • Reid: as one worked down the stack, I’d discourage anyone allocating on the stack dynamically. It enables a lost of backend bugs
    • Aaron: I don’t expect any runtime support required here
    • Corentin: I’m not sure how it’s going to work in C++. exceptions and stuff
    • Corentin: I don’t want to repeat VLAs
    • Corentin: there is an argument to be made to get it into C++, but someone has to do the work
    • Aaron: C++ exceptions are analogous to setjmp/longjump exceptions for C, and has to be handled
    • Corentin: can you explain return goto?
    • Aaron: kind of [[musttail]]. When I looked at the paper, there’s a lot of divergence between Clang and GCC on musttail, but the paper allows all of implementations. I don’t think it’s worth it to support it as a language feature, because trigraphs are enabled more often than musttail.
    • Reid: maybe popularity doesn’t convey how often it’s used in runtime
    • Aaron: my point on the TS is that we already have musttail, and we don’t want to duplicate the functionality. If WG14 decides to roll it into the IS, I’m not opposed. But TS is not worth the effort
    • Corentin: I think TS would have value if multiple implementations would pick it up, so that users can rely on it. It comes up in C++ often enough, especially with coroutines.
    • Reid: another interesting wrinkle to this. I added musttail to LLVM, initially only to x86. I envisioned it to be something that never fails, but instead we ended up with backends best effort to emit a tail call
    • Aaron: which is the reason why the wording in RFC is as lax as it is: because some architectures can’t do tail calls.
    • Corentin: what users want is guaranteed tail call. If it’s in the standard, backend people will stop being lazy
    • Shafik: can we make an effort to make musttail work better, instead of going through the committee.
    • Aaron: there’s a common implementation practice that people want to standardize. So the question is whether we want to spend time on this
    • Corentin: there’s only the value in this if we can provide the guarantee
    • Vlad: but guarantees that backend can’t fulfill is a hazard for portable libraries
    • Corentin: I think there’s still a value of this working only on platforms that support it
    • Shafik: but why we need a new syntax?
    • Corentin: portability
    • Aaron: part of the concern is that: code is working, but then you enable AVX-512, it suddenly stop working
    • Corentin: I think people want a hard error there
    • Reid: so users know when it doens’t work, and I’m getting linear stack usage
    • Aaron: it’s useful to be clear that it’s not a portable feature
    • Corentin: it’s portable in a sense that if it work where it’s working
    • Reid: the feedback for the committee is that we’re raising the bar for implementations
    • Aaron: what I’m hearing that we don’t have a volunteer to implement the TS, but we want more guarantees
    • Corentin: I think we’re going to get issues to implement tailcalls in scenarios that it’s not working in today
    • Aaron: Clang and GCC gives different answers
    • Vlad: we should talk to backend folks
    • Aaron: I can bring this up with Nikita
    • Aaron: the third one is _Optional. We already voted no, so I don’t expect anyone change their mind
    • Aaron: the same TS that does tailcalls does constexpr functions in C. They aim for C++11 constexpr functions plus a couple nice features. I think we’re interested in it, because we already support it
    • Vlad: side effects?
    • Aaron: no
    • Corentin: we have a mature implementation, so maintenance is remembering which features are enabled in which language mode.
    • Corentin: in C++23 and C++26, everything can be constexpr, but now we need to limit that for the TS
    • Aaron: this TS is going for small implementations that don’t have constexpr implementation at the moment. They want a minimum subset implementable everywhere. If you implement more, do what C++ does
    • Hubert: they say “conditionally supported”, so we don’t need to even diagnose that?
    • Aaron: I don’t recall what TS said. “Implementation-defined”, I think, but it was 2 days ago
    • Aaron: it’s a TS, so we don’t have to emit pedantic diagnostics
    • Corentin: what is the point? We already implement it, so we know the answer
    • Aaron: this is from the time when they didn’t want to say no
    • Ariel: about defer. We don’t want additional storage requirement when defer is used.
    • Aaron: it’s no different from [[cleanup]] when used, but you need to record somewhere that you need to clean up stuff
    • Aaron: contact Rajan
  • Vlad: Clang’s C++ conformance was discussed in LLVM Qualification WG meeting on August 5th
  • For general awareness (can be pulled up for discussion on request)
    • Hardening (RFC)
      • There is a discussion of this happening at the memory safety working group tomorrow
    • New text diagnostic format (RFC)
    • restrict support (RFC)
    • CHERI upstreaming (RFC)
    • GitHub PR auto-merge feature (RFC)
    • libc++ want to take dependency on Boost.Math (RFC)
    • Driver option to select C standard library implementation (RFC)
    • Maintainer policy discussion (thread)

Meeting Agenda - July 16th, 2025
Agenda

  • Clang 21 branch happened yesterday, rc1 is expected Friday, rc2 should be two weeks after that
    • Are we aware of any significant regressions we need to be aware of
    • Vlad: libclang ABI broke by removing functions
    • Ambrose: PR for the fix already merged and put into the release branch; implementations just print an error (as they did before when ARC migrate was disabled)
    • Aaron: Shafik has a project for tracking regressions
    • Shafik: I do, but it may not be public yet (trying to make it public so others can see).
    • Clang Regressions · GitHub (it’s not public, only specific folks added)
    • Aaron: I’ll reach out to admins to make this public, will CC Shafik
    • Vlad: Eli noticed and fixed an issue with a new libclang function that was landed with the wrong version for ABI. (It was a timing issue with Clang 20). Already backported
    • Shafik is bisecting regressions, almost all can be bisected
    • Corentin: I fixed all of them. Some are 2-3 releases old
    • Aaron: the later one are more important
    • Corentin: several that are left are hard to fix
    • Corentin is taking ownership of old unmerged PRs
    • Aaron: old regressions are hard to revert
    • Corentin: many come from the fuzzer
    • Aaron: I’m checking whether they are relevant
    • Shafik: I consider any fuzzer-generated regression in the last 2 releases, I consider it serious. We can track that. If it goes back 10 releases — fine, too much to track
    • Aaron: sounds reasonable. Crashes are not security-sensitive. I’ll go through regressions to see anything worthy of a release block
    • Hubert: I tend to agree that compiler is not security-sensitive. I’ve heard that libclang might be used in production environments
    • Aaron: I don’t think we ever decided one way or another
    • Reid: We have a security group, which came up with a policy
    • Aaron: We have a security group, and they came up with a policy what’s a security concern. Compiler is not considered security-sensitive. Taking a look at libclang docs, we don’t document anything
    • Reid: We’re good as long as we make it explicit for users that we can’t be fuzz-clean. Use sandboxes, because we don’t have resources
    • Aaron: Sandboxing is the answer we’ve been giving people with untrusted inputs
    • Hubert: Sounds reasonable. Hopefully libclang users investigated this
    • Aaron: link to the policy where we recommend sandboxing: LLVM Security Response Group — LLVM 23.0.0git documentation
    • Aaron: if someone came up with a crash which is a security issue, we’d treat it as every other bug
    • Reid:
    • Hubert: we’re definitely talking about untrusted inputs
    • Reid: we need to improve the docs on the security stance of the project
    • Aaron: agreed. The policy is a bit vague
    • Reid: we’ll discuss AI policy in project council
    • Reid: AI-generated issues are a topic of discussion for an upcoming conference
    • Aaron: I found that AI contributions become worse with time. Not clear when AI ends and human text begins, but onus is on the reviewers to ask people if they are asking in a bad faith. I hope we can find the right balance, because fancy AI autocomplete is fine, but we can’t waste time on AI-generated replies
    • Shafik: AI responses are also huge, because I don’t want to waste my time. Contributors learn, but AI doesn’t learn from reviewers.
    • Hubert: same experience here. Too many points in AI responses, and they are all subtly different.
    • Aaron: I ran into an issue where LLM came up with many points why the issue is important
    • Reid: Agreed. Writing PR or comment used to have inherent worth, but now writing is easy, while reading is the bottleneck. Contributors shouldn’t hide that they use AI
    • Aaron: Good observation on amount of writing corresponding to amount of thought put into the writing
  • 64-bit source location discussion happening tomorrow at 4pm ET
    • https://meet.google.com/ktv-ifef-bym is the meeting link
    • Aaron: unfortunately bad time for Europe folks
    • Aaron: “can we eliminate duplicated source locations?” Is what we’re going to discuss. I think RFC has the consensus to move forward, but ensuring that we’re not missing anything
    • Corentin: talking to multiple people, have been taught opposite things
    • Aaron: same here
    • Aaron: the meeting is announced in the topic an PR
  • Project council meeting happening tomorrow at 2pm ET: LLVM Project Council Meeting - July 17, 2025 (https://meet.google.com/ojz-umdr-gfg)
  • Bounds safety
    • Aaron: Discussion is continuing, but trajectory hasn’t changed. Folks will continue to find the common ground. The only consensus is consensus against GCC-style forward-declared parameters.
    • Reid: Not up to date on the thread. Would be nice to be compatible with GCC, but we need to move forward
    • Aaron: Yeoul is contacting privately on design: attributes are going to be a bit of a decl attr and a bit of type attr. Multiple levels of pointers might be counted by different things, which is a property of a type. They have been hiding a lot under a macro, but that only works for GCC-style attributes, but is not going to work for standard attributes. This wasn’t recognized by the original RFC, but is orthogonal to the RFC currently discussed
    • Corentin: noreturn attr does something weird when it’s spelled in GCC way
    • Aaron: agreed. One of the primary driving reasons behind standard attributed was to avoid “sliding” them, which makes them hard to ignore. Want to preserve this for standard attributes
    • Corentin: both committees don’t really understand that, and maximize the convenience
    • Reid: agreed. This reminds me of other migrations
    • Aaron: we have precedent for attr that are decl or type, but the syntax position is still different. Apple is willing to change the existing code if design changes come
  • Recently discovered on AIX that the definition of NULL is conflicting with other system headers; plan to add wrapper headers (a number will be standard headers).
    • Aaron: don’t we already have a wrapper header
    • Hubert: we still need to wrap it
    • Aaron: so for the headers that need to include stddef.h…
    • Hubert: yes, we need to wrap them. Behavior of your TU might change depending on the included headers
    • Aaron:
    • Hubert: you can get 0L instead of 0
    • Reid: my favorite manifestation of this is 32 bits of 0 instead of 64
    • Aaron: yeah, well-known issue with the standard
    • Aaron: there is awkwardness on who provides what. Musl ignores all compiler headers, injecting themselves in the right place. Glibc is different
    • Hubert: we generate headers that ends with guards
    • Aaron: sounds reasonable. Put me on the patch
    • Corentin: in C++26 the definition of assert macro have to be different. C way doesn’t work for scoped enum. Maybe we want to provide assert from the compiler. In C++29 we might use contracts to implement assert, so we can’t rely on C definition
    • Aaron: I thought libc++ has to provide them
    • Corentin: there is cassert. But we want cassert and assert.h to provide the same thing
    • Aaron: when you in C++ include C header, you want to get what C++ standard says
    • Aaron: worth looking into
    • Corentin: we’re past the point of divergence between C and C++ headers
  • SHIFT-jis
    • Hubert: there was discussion on yen sign. We’ve got to the point where we need to check that. Yen sign and overline sign are considered backslash and tilde. For the purposes of deployment with ICU, we’ll use encoding where they are backslash and tilde. Coincidentally, if you indeed them, use IBM codes.
    • Corentin: I don’t like that. If there’s yen in the code, it should be there. We shouldn’t perpetuate this mistake forever. I’m not happy with GCC behavior
    • Aaron: how pervasive the problem is?
    • Hubert: I suspect that it’s treated as backslash.
    • Corentin: there’s no way to tell if you used yen or backslash in the source
    • Hubert: compilers we’re moving from do consider yen to be a backslash
    • Aaron: I ran into this on Windows in paths
    • Corentin: yes, it’s pervasive, but we want to fix this in 10 years
    • Hubert: trying to clarify the scope of your concern. This is not affecting any UTF-8 code. This only affects shift-jis sources.
    • Corentin: then shift-jis can be an execution charset
    • Hubert: then it’s ambiguous
    • Corentin: yeah
    • Aaron: my concern is that users in this situation are not going to move off the old behavior. 10 years from now we want people to be on UTF-8
    • Corentin: we should issue warnings. When japanese company treats their code as shift-jis, and they start to work with overseas companies, the stuff will mix up
    • Hubert: yes. We’re not changing status-quo
    • Ariel: what are the implications for EBCDIC
    • Hubert: for latin-1, you can correctly convert characters beyond 7F to UTF-8. Currently it’s not possible, I think. On Z/os, a lot of input is treated as latin-1. With -finput-charser, it might be fixed
    • Aaron: -finput-charset is where the solution lies.
    • Aaron: we should have a diagnostics when weirdness is going on
    • Hubert: diagnostics for this might be hard, because conversion is happening early
    • Ariel: UTF-8 everywhere in 10 years is unrealistic. EBCDIC will be there
    • Aaron: I made that statement, and I agree. I mean people who are interested in modernizing their codebases
    • Corentin: EBCDIC is growing, and shift-jis might be going away at some point
    • Hubert: legacy systems tend to work forever

Meeting Agenda - July 2nd, 2025
Agenda

  • Corentin: no one is working on upstreaming reflection
    • Aaron: unfortunate, but we’ll get to it when we get to it like other standards features. Hopefully someone is interested in helping to upstream what Dan had in his fork before it bitrots.
  • Vlad: 64-bit source locations (RFC)
    • Question is: do we think it’s fine to spend 4 more bytes on every source location, does that mean we eventually need 128-bit source locations?
    • Ambrose: 64 bits are a LOT; I don’t think there will be a need for more
    • Corentin: I chatted with folks at the C++ meeting and one of the things that came up is that 32-bits is already a lot. If you have a billion source locations you often cannot represent that AST due to the size of it. Some folks (Michael Spencer in particular) think this may not be necessary. But there are conflicting opinions on that, but it would be helpful to know what the actual need is.
    • Vlad: last time I checked, the size of ever decl node is approx 100 bytes. So 200 GB of AST?
    • Aaron: Agree with Ambrose; can use higher bits for packing. We have bitfields in AST, and we’re run into their limits quite fast.
    • Corentin: most of the source locations are not used, and are just deprecated. Some of them come form the preprocessor, some from modules
    • Aaron: agree, we have shenanigans in TUs
    • Corentin: can we reduce the waste?
    • Aaron: worth bringing up on the RFC
    • Corentin: even on google scale another limits will be hit
    • Vlad: if 64-bit direction is taken, we can reserve a lot of bits for future use
    • Aaron: if authors say they can’t reclaim 4% of memory overhead, are we good with that?
    • Ariel/Vlad: I have concerns about the extra memory overhead
    • Vlad: Slippery slope of allowing the change without reclaiming overhead right away
    • Ariel/Vlad: if it’s space neutral, it’s fine (though some space overhead can translate into time overhead)
    • Aaron: do we have a request for them to explore the wasted source locations?
    • Aaron: I’ll schedule a Clang Area Team meeting, ensure that Michael Spencer is marked as a critical attendee
  • Hubert: -finput-charset
    • Hubert: Caught Corentin over lunch during Sofia, plan right now has evolved slightly. What we’re trying to do is do the entire file conversion just before the preprocessor gets to see the buffer. That helps because then we actually know it’s source code being parsed and will handle headers as well as source files that are listed on the command line.
    • Hubert: The interesting part is what happens when the conversion fails. We’d like to produce some kind of diagnostic, but it’s likely to be the offset to the error. We’d like to “recover automatically” by then falling back to UTF-8. That’s kind of the status quo already.
    • Hubert: people who used -finput-charset know that it’s not good, because your headers might be in a different encoding, so UTF-8 fallback is useful.
    • Aaron: does the conversion happen in lexer?
    • Hubert: yes (“before”)
    • Hubert: there are more than one place where the file is opened. We could handle each of them, but we decided against it
    • Corentin: so the preprocessor sees only one source buffer
    • Aaron: would be nice to start with a correct implementation followed with an performant one.
    • Hubert: internally we have a pragma, so our direction is going to be compatible with that
    • Corentin: this is what GCC does: converting sources in one go before preprocessing
  • Vlad: WG21 meeting in Sofia
    • Vlad hung out in Core all week
    • Reflection, function parameter annotations, template for, ill-formed meta functions now throw constexpr exceptions rather than being ill-formed
    • Corentin: Had a chat with Michael Spencer about constexpr exceptions. Modifying -fno-exceptions means you cannot have more than zero exceptions in flight. That would fix the meaning of that flag. This would be for both constexpr and runtime exceptions. This implies the keywords are fine
    • Core looked at ~5 core issues around #embed, particularly around parameters
    • Aaron: today we recognize the keywords, analyze them, and diagnose them
    • Corentin: diagnosing during parsing
    • Aaron: I’d like to check the sources
    • Ambrose: BuildCXXThrow
    • Aaron: not a matter of parsing
    • Aaron: [learning how to use if constexpr]
    • Aaron: so it’s not on parsing, but during evaluation
    • Corentin: yes
    • Aaron: I’m not sure how I feel about this
    • Corentin: senders-receivers use this
    • Aaron: people use -fno-exceptions for two different reasons
    • Vlad: that’s why I asked whether Michael’s clarification should be the answer for the default behavior of -fno-exceptions
    • Aaron: we also have -fno-cxx-exceptions, which leaves SEH enabled
    • Vlad: looked at #embed and parameters for embed
    • __has_embed and __has_include can only report true for something when the file can really be opened for reading, even if you do it with limit(0). So you can open the file but not run into access denied.
    • Aaron: do we need to make changes to the implementation?
    • Corentin: we have to investigate; it’d be nice to do it before Clang 21
    • Vlad: you also have to look at core issues, that modified the status quo from the paper
    • Corentin: we need to synchronize between C and C++
    • Vlad: Jean Heyd promised to do that.
    • Vlad: what I heard does not change our optimized path of handling embed. It was more about macro expansion in parameters, and that sort of stuff
    • Mariya: there’s an issue on GitHub for embed in C++26, can we add the core issues and papers to that issue? [clang] Fully support #embed in C++ · Issue #127610 · llvm/llvm-project · GitHub
    • Vlad: sure, I’ll do that
    • Corentin: does C23 has offset in #embed
    • Aaron: C23 does not have offset parameter for #embed
    • Corentin: is there a dependence on the order of offset and limit?
    • Aaron: should issue a warning if the order matters
    • Vlad: reflection also got spicing of base class subobjects. So if you get a reflection of a base class, there’s now an entity to represent that relationship. Now you can splice this thing, helpful for member class expressions. This might have implications for access check wording, but still in the works
    • Static string arrays are in C++26
    • Reflection of C++11 attributes was rejected by EWG, but the author may come back. Too late for C++26 regardless.
    • Constexpr virtual inheritance was added; implementers were in the room and despite unanimous rejection from implementers in Hagenberg, it was decided by implementers those issues were not really blocking and so the feature is in.
    • declcall paper did not go in, has issues around conversion functions
    • Corentin: I opened an issue for Alisdair’s preprocessing paper, because it’s too restrictive
    • Aaron: was the paper presented to WG14
    • Corentin: I think the paper is an improvement, but in few places it should be implementation-defined
    • Aaron: C standard says something about integer literals in preprocessor
    • Hubert: Alisdair’s argument is that implementations can continue accepting what he makes ill-formed as conforming extensions. Committee in the future can specify behavior that is not compatible, but the risk is low
    • Aaron: I don’t understand why the standards committee has to be involved here
    • Shafik:
    • Hubert: Alisdair had examples for everything he changed, and diagnostics for all of them seem to be implementable
    • Aaron: now we’re supposed to always issue a pedantic error
    • Hubert: yes, pedantic mode is conforming mode
    • Aaron: the issue is with the warning-default-to-eror part. Anyway, we’re not going to change anything for practical purposes
    • Corentin: we don’t diagnose directives inside macro expansions. Was IFNDR apparently
    • Aaron: do you know if Alisdair is going to bring this to WG14?
    • Corentin: I don’t think so
    • Corentin: not enough attention to C
    • Aaron: it’s not useful to change preprocessor from only WG21 side
    • Aaron: was it on SG22 plate?
    • Corentin: don’t think so
    • Corentin:
    • Hubert: I went through the paper, I swear Alisdair said that it’s already diagnosed
    • Aaron: P2843R3? Yes. it wasn’t discussed in SG22
    • Corentin: you’re right, we have a pedantic warning
    • Corentin: I don’t understand the motivation of not allowing it
    • Aaron: macro expansion is hard
    • Hubert: yes
    • Vlad: type ordering paper is in
    • Corentin: we should review Ilya’s PR against that now, I’ll do that
    • Hubert: for the directive in macro expansion case, MSVC treats it as non-directive
    • Aaron: I wonder what the implications are for #embed
    • Hubert: if someone wants #embed in an expansion, they can bring a paper
    • Aaron: our implementation is not going to change
    • Hubert: having worked with tests outside, you need pedantic to get all the diagnostics
    • Aaron: if the WG 21 intent is to get it diagnosed, it’s not happening
    • Hubert: that is not the intent
    • Corentin: the intent is that your program is not UB
    • [ Skip back to EH discussion because of late arrival by Hubert ]
    • Hubert: so we change the status quo?
    • Hubert: the exception behavior discussion is starting to sound a lot like -fignore-exceptions behavior, worth keeping in mind
  • Vlad: Using a C++ package manager repo as a corpus of C++ code we can run experiments on
    • Vcpkg made design choices that can make it suitable for this
    • If we can compile the code, we can run clang-query on it
    • But this needs significant hardware resources to compile the whole corpus in a reasonable time
    • Compile_commands.json is one of useful artifacts of the build; we can see how used our compiler flags are
  • Vlad: Bounds Safety RFC updates
1 Like