Historical Clang Language WG Meeting Minutes (Apr 2024-Mar 2025)

Clang Frontend
1

Meeting Agenda - Mar 19, 2025

Agenda

  • Area Teams starting up
    • Clang, MLIR, and infrastructure have all started to meet.
      • Teams are starting to have meetings
      • Project council is not running yet, but will soon
      • Meeting will be on community calendar
      • Not a set day and time, depending on availability of people
    • LLVM & Project Council are still not running yet, but are expecting to start up soon
    • Keep eyes peeled on RFCs; we’ll announce in a comment in the RFC if an area team meeting is being held to discuss the topic further
  • Backporting for 20.x is open now
    • Keep in mind that the ABI is frozen, so any change which impacts Clang ABI is likely a bad candidate for backporting
      • Adding a new diagnostics is an ABI break, because of a new enumerator
  • [Windows SEH] Crash and assertion hit on Windows SEH since 17.1.x · Issue #109576 · llvm/llvm-project · GitHub
    • Have ~5 related issues all in the same area
    • Maybe disable /EHa so users don’t hit this?
  • [CI] Clean up runtimes builds by boomanaiden154 · Pull Request #131913 · llvm/llvm-project · GitHub
    • Precommit CI has slowed down recently
    • Lucile has not yet weighed in on why the slowdown is happening
    • This risks losing test coverage, such as modules testing
    • Not too long ago we had to disable lldb testing in Clang precommit CI for performance reasons, so removing even more test coverage is worrying
    • C++26 + modules may be the most important configuration to keep, if we have to drop anything
    • Could be an issue with clang’s performance rather than CI machine performance (Aaron has seen some issues with template instantiation depths in Debug modes on Windows recently). Could be death by a thousand cuts
    • Reid: need to make tradeoffs between configurations that are the most important to the community, limited resource availability. Performance testing is especially expensive, and we currently run precommit CI on every change to a PR.
    • This might be an infrastructure team problem. What input do we want to give them for how to resolve this?
    • Aaron: long-term graph of compile time performance of Clang is horrible
    • Vlad will attend the infra meeting this week and bring the topic up there.
  • Triaging crash issues have shown a number of regressions
    • Could use help on issues with the needs-reduction label
    • So far not missing any critical regressions, at least as far as we can tell.
    • A lot of the regressions are against 17-18
  • Nullability attribute work needs some extra information in the AST regarding sugared template substitution nodes. But adding a flag would block the work we’re doing on resguaring. Fixing this may induce performance regressions. May not be possible to resugar template aliases perfectly (but may work sufficiently for their needs). Matheus will try to add substitution nodes back (and get rid of the driver flag). Could have flags that are usable for Clang tooling (clang-tidy) but not exposed to users.
  • Hubert is wondering if we can split off the meeting minutes for the language working group because it’s 100+ pages right now
    • Aaron: sure, I’ll do that for next time
    • Aaron: will investigate putting the old notes into a git repo or dumping into a Discourse post (or could live in a folder under clang/docs)

Round Table

  • Vlad
  • Tony
  • Tom
    • Hoping to put up some SYCL PRs this week
  • Shafik
    • Working on untriaged issues, got through a bunch of them. Found a lot of good bugs
    • Working on static analysis-found issues
    • Trying to bisect regressions to figure out the responsible commits
    • Not able to work on DFP currently; on hold until internal work is finished
      • Tue thinks it might be a good GSoC project if we have something up and sort of working by next year
      • If anyone wants to pick up DFP work, that would be a good thing (not made significant progress in the past two years), will collaborate as needed.
  • Reid
    • Helping a bit on vector deleting destructor work
  • Matheus
    • Starting to work on resugaring again, picking up previous patches from Phab. Will make another post on Discourse as it gets closer to complete. Has a fork up on Compiler Explorer (clang resugar) if anyone wants to play with it.
  • Mariya
    • Vector deleting destructor patch was reverted for two issues, working on fixing those.
      • First issue should be fixed
      • Second issue is a runtime issue, only reproducible on 32-bit systems and only with lld. Harder to pin down the fix for this one.
  • Hubert
    • Hoped to get to character set conversion utilities, but got pulled off on compiler-rt work (https://github.com/llvm/llvm-project/pull/74516)
      • Corentin will help look at it
    • -finput-charset support is getting some user requests (not just exec charset)
    • Target features for PowerPC are not necessarily consistent with what flang and rust would do. Looking to set up something in LLVM a way to understand what target features are set for which CPU names; have Clang rely more on that instead of parallel implementations. Initially for PPC, other targets can opt in if needed.

Meeting Agenda - Mar 05, 2025

Agenda

  • How is the Clang 20 release going?

  • How did WG14 go?

    • Met in Graz, Austria
    • Saw about 65 papers aiming for C2y, accepted/encouraged more work on all but three
    • Implementers are getting a bit frustrated at taking all features
    • May be switching from weak consensus model to strong consensus model
    • Nothing accepted at the meeting for C2y that is a major issue for Clang
    • Helpful to have more downstream implementers in the room (currently represented are Intel, Apple, and IBM; could use folks from Google and Microsoft, could use folks from llvm-libc for library coverage, could use folks from LLVM for backend perspective)
    • Erich has some Microphone to USB interfaces that could be used to help with audio issues. Would still need to get the microphones themselves.
    • Pittsburgh in sept is the next scheduled meeting, may move to virtual meeting though
    • Corentin: what is the value of having a TS for defer? It’s a small feature. We don’t have good success with TSes in general.
    • Aaron: it’s small enough, want to have it documented as “fully experimental” so we can change as the standard changes. I hope to implement this TS.
    • Erich: lots of overhead to having TSes which reduces the value. Whitepaper is a slightly less heavy option; basically a TS but without ISO process behind it.
    • Hubert: don’t care for the editorial aspect of TS, but may lose the balloting aspect of it as well, which is a loss.
    • Erich: could ask the convener to do unofficial ballots for getting NB-ballot-like voting

  • Flowing off the end of a function, should that be an error?

    • WG21 CWG having a discussion about this topic, wondering where people lie on it
    • Some folks think optimizations are too aggressive here in terms of not running destructors.
    • Should it be ill-formed or should Core do a more nuanced approach?
    • Aaron: CFG means we have a lot of false positives, so making it ill-formed is likely to break a lot of code.
    • Ambrose: [clang++] Unnecessary warning "non-void function does not return a value in all control paths" · Issue #111509 · llvm/llvm-project · GitHub
    • Reid: this also presupposes compilers can support all of the various “unreachable” idioms that are used in practice. Inline assembly, volatile nullptr dereference, etc.
    • Reid: isn’t CFG optional?
    • Aaron: It should be, but it isn’t (-Wall/-Wextra enables some diagnostics)
    • Reid: still perhaps a good reason to push back on standards-based requirements for CFG
    • Aaron: agreed, it negatively impacts compile times and it has heuristic-based diagnostic which means it’s got false positives
    • Corentin: I have the opposite reaction; falling off the end of a function is a massive security/safety concern. We should make it an error. Fixing it is easy by putting in unreachable(). That said, the standard is going to struggle to specify static analysis, so it may not be a standards mandated thing. MSVC does make it an error by default and has always done that. Portable code should already address this.
    • Joshua: can alleviate a lot of the problems by adding a return value instead of diagnosing as a difficult case. The optimizer can handle removing that. So the security concern may not be worth the problem
    • Aaron: conditional code makes it harder (assert()), but still want to get this as a matter of QoI. Standardization seems hard though.
    • Reid: -Werror=return-type, effectively?
    • Aaron: that’s what we’re trying as QoI, yes
    • Shafik: Java got this right, if you can’t prove it returns, then it’s an error.
    • Hubert: I think false positives will get a bad reaction, but we can see; it’s not the first time we’ve enabled warnings as errors that become things people turn off across the board. In terms of committee, we have nothing we can propose to the committee. Clarifications they’re going through are reasonable.
    • Tom: agreed with what Hubert was saying, as long as we’re running destructors, that’s good. Do we emit a ud2?
    • Shafik/Ambrose: I think we do.
    • Ambrose: according to CE, you get a ret instruction and that’s it, irrespective of optimization level
    • Joshua: depends on flags
    • Reid: tangled mess of conditionals within LLVM; I wish we could commit to a trap.
    • Tom: regarding warning as an error, if we can do that with a low false positive rate, that’s awesome. Does GCC do that as well?
    • Shafik: not currently
    • Aaron: has anyone reached out and asked?
    • Ambrose: warning is on by default, but not as an error
    • Hubert: CE LLVM IR for a function that flows off, we do have an unreachable there. Adding an automatic variable that needs destruction, the destruction doesn’t happen. Adding a return statement causes the destruction to happen. Clang needs to do work to implement it.
    • Shafik: the UB is that we’re not returning a value (unconditionally, in C++). Not the same in C.
    • Reid: are we non conforming in C?
    • Shafik: no idea, I’ve not tested, but C has no destructors.
    • Tom/Ambrose: attribute((cleanup)) could see that
    • Joshua: conformance in C probably needs to return poison instead of unreachable
    • Reid: that sounds like something we need to fix
    • Aaron: Shafik, can you file an issue about the C bug?
    • Shafik: can someone share an example?
    • Hubert: I’m not seeing the unreachable in C in the IR.
    • Ambrose: in C++ we do emit a ud2, but we don’t in C. In C we don’t even have an unreachable, we just allocate the variable and load it uninitialized and return that
    • Aaron: that’s conforming then, the UB only comes when trying to use the value.
    • Hubert: we basically give you undef
    • Reid: which is what the standard says to do. So the defect it purely limited to C++, we don’t run cleanups when we should.
    • Ambrose: in C++ we also call llvm trap, which might be causing the ud2
    • Aaron: Shafik, the issue would be just C++ related to not running destructors
    • Hubert: you can wait until the core issue is blessed by core, but nobody is fighting against that, so I expect it will get in
    • Shafik: I’m wondering if there’s a way to observe the difference
    • Hubert: observability is if your destructor throws or calls exit()
    • Shafik: maybe that will subtly break something, but probably fine
    • Hubert: we’ll call the dtor in the case when we are supposed to call it, so I don’t think this will subtly break anything for anyone.

  • CPATH

  • Tue would like to do something for aliasing the math functions for long double or float128; is that allowed in C or does the standard require different functions to be totally different?

    • Hubert: what do you mean about aliasing?
    • Tue: when long double is double, I want sigl to point to sin
    • Hubert: won’t really have a problem with that as an implementation detail. Is this a question about taking the address of the function and see if they’re the same?
    • Tue: yes
    • Hubert: I think the standard says that they’re different functions
    • Aaron: I agree, I think it would be observable if you did the aliasing
    • Hubert: may be worth raising with the C committee
    • Reid: prior art may be Neibloids in the C++ standard. Don’t consider standard library APIs to be address stable.
    • Ambrose: yeah, wasn’t that for std::move and friends? Neibloids was you can’t find them via ADL?
    • Joshua: must be callable from their name without a header file
    • Tue: that’s fine with asm aliasing
    • Reid: yeah, need to come back to the standards body for a change to make the addresses not significant.
    • Tue: code folding and ifunc may point to the same one.

  • Should we increase meeting length, drop round tables, have additional meetings? This is the third meeting in a row where we didn’t get through round tables, so it suggest we may need a change.

Round Table

  • Didn’t get to them.

Meeting Agenda - Feb 19, 2025

Agenda

  • How is Clang 20 release going?
  • How did WG21 go?
    • Aaron was delighted^Whorrified.
    • Corentin: already updated the language status page, and opened some issues related to new changes
    • Contracts made it in to C++26, without pre/post conditions on virtual functions
      • Hubert: there may be ODR concerns with the feature, have we discussed?
      • GitHub - davidchisnall/contracts-do-not-belong-in-the-language: Draft paper arguing against P2900
      • Tom: the concerns only apply to some implementation strategies; we have flexibility. Should be discussed in SG15
      • Hubert: if you have a TU with an inline function and you have a specific contract checking mode that is callee checked, the caller may assume that the callee checked the contract. Which may not work if inlining fails and you pick up another definition.
      • Corentin: could there be some linker-based approach to pick one?
      • Hubert: or could establish a name mangling for it, but only works if it’s part of the declaration.
      • Corentin: Eric F has been in discussions on the topic but has not implemented anything
      • Tom: mangling would be novel for the choice of compile time contract semantic
      • Hubert: mangling won’t help for explicit template instantiations, but it can be implicitly instantiated in another TU, and if that happens, you don’t know what semantic you’re going to get.
      • Aaron: we should have another meeting to discuss this specifically; it should include Tom, Corentin, Hubert, Aaron, and Eric F (as well as anyone else interested). Aaron will try to get a meeting scheduled.
    • Bloomberg folks have worked on a fork of Clang to implement this, are planning on starting to upstream in the near future
    • Trivial relocation and concept parameters are in, Corentin is planning to work on them
    • #embed is in C++26, we already support it in C++ as an extension
      • Still need to do some bug fixes with it
    • A lot of new library features
    • Trivial unions made it to C++26 but new issues were discovered and so we may not want to implement right away until the feature settles down
    • Partial program correctness; what are we going to do about it? It introduces barriers to prevent time travel UB. Need LLVM input.
      • Aaron will bring it up during the monthly maintainer meeting
      • https://wg21.link/p1494 (r5 was voted in, will be in the March mailing)
      • Hubert thinks it makes no practical changes whatsoever, it basically says you can’t erase volatile accesses before UB, which is what everyone already does. It’s still weaker than the C wording for volatile accesses.
      • Tom thinks we still need std::observable call, which will be needed for contracts; could just model a volatile access of some kind maybe? Needed for the “observe” semantic in contracts.
      • Hubert thinks that may not be the correct motivation; for observe semantics, it means you do get the logging and the logging does not get erased. If you move past that semantic and the contract is violated, your code has UB, then you get the UB after the logging.
      • P2900R14 section 3.5.3 (will be published in the March mailing) has the prose for the intent.
    • Reflection will continue to have define_aggregate
      • Aaron has an in-progress RFC on this, won’t post until Reflection makes it to C++26
    • constexpr virtual base classes was forwarded, but there are implementation concerns regarding ABI breaks (especially Microsoft mode)
    • Profiles did not make it to C++26, there’s a pseudo-study group for it, will ship a white paper rather than a TS. It’s a novel approach, so there’s some uncertainty on how the feature will evolve. The paper still goes through EWG->CWG->Plenary
    • launder less paper is now waiting for the author to come back to EWG, so it may or may not come back.
    • non-deterministic pointer provenance (P2434) is in a similar state, but likely will come back, but we do not know yet in which form.
      • We should put Davis in touch with Nikita and perhaps Joshua Cranmer so he gets feedback from backend folks. Aaron will take care of this.
    • Type ordering paper was pulled back from plenary because it wasn’t seen by Core, but it should still hold that ordering will be implementation-defined
      • Some concern for type_info, but platform-specific for folks using the string to do the type info ordering and equivalence. Hits IBM AIX.
      • Will use name mangling for ordering and equivalence
      • Cases where mangling collides should not be possible to observe using new constexpr type ordering facility

Round Table

  • Aaron
    • WG21 last week, WG14 next week, otherwise reviews
  • Ambrose
    • Getting back onto reviews
    • Trying to get -Wreturn-type as a warning default error now, has lots of test churn
    • Refactoring isAnyPointerType so it actually makes sense, coming up with a better API for it
  • Ariel
    • Mostly been working on frontend stuff downstream
  • Corentin
    • WG21 meetings last week, tried to say no to things, alas was ignored
    • Upstreaming trivial relocation and contracts
    • Need to follow up with Microsoft on a new mangling for lambdas that does not depend on the outer context and is closer to Itanium
  • Hubert
    • WG21 meetings last week, still digging out and has more committee work to do
    • Was pointed out that use of defined (as an identifier) as a result of macro expansion, Clang has two diagnostic behaviors: one for function-like macro and another for object-like macro. People are pushing GCC to do the same, but there are counterexamples that may make Clang’s behavior less desirable. Currently under one warning group, which is a bit messy.
  • Mariya
    • Have a PR for MS-compatible vector deleting destructors, looking for feedback
      • Reid may be able to help but doesn’t have the time, can try to find someone else to help with; Tom may try to get to it in the next few days
    • Working embed bugs, has questions to discuss
    • Hubert: still a mess in terms of standardization, wording issues
  • Reid
    • Nothing direct happening aside from working on LLVM struct layouts (impacts LLDB and no_unique_address)
    • Also discussed better crash reproducers for modules. This was discussed in the Clang modules working group meetings, Tom suggests sending folks there if not already involved (talk with Bruno [Meta] and Cameron [Microsoft])
  • Tom
  • Need to start with Tony, Timofii, and Vlad next time because we ran out of time

Meeting Agenda - Feb 05, 2025

Agenda

  • We’ve branched for Clang 20
  • WG21 meetings Feb 10-15 (Hagenberg, Austria)
    • EWG (targeting C++26)
      • Reflection
        • Non-static data members of closure types – no longer allowed, yay!
        • Conversion functions of closure types – mostly about calling convention variants; will probably allow reflection to access all of those, since they exist
        • access_context – had opposition in Poland, but authors and us agree this is important; will push for it in Hagenberg. Status quo is that all private and protected members are always returned, we’re pushing for access_context to require an explicit decision at the call site.
        • Split define_aggregate from Reflection – unsure how it will go over, authors are not in favor currently, but we’re pushing for it to reduce risk of not getting reflection in C++26
        • Complete class contexts – define_aggregate should not be allowed in complete class context (decided in Poland), wording of the paper has changed twice in significant ways since then, and the authors were planning to try to push for complete class contexts again. We found another example that could be problematic; working with Dan (paper author) on it.
          Compiler Explorer
      • Immediate-Escalations Expressions
        • is marked for C++26, trying to limit them. A bit difficult to know what the final state will be because there are several papers in the same space. Clang has some issues in this space already, Corentin has been working on fixing them. Basic idea is to have a consteval type (can only be used at compile time, cannot be used at runtime). Not certain the feature is fully baked.
      • Constexpr coroutines (paper, counter-paper)
        • counter paper is about implementation concerns, we should probably support that.
        • unclear benefits to having constexpr coroutines; what’s the cost-to-benefit ratio?
        • Shafik had concerns in Poland and continues to have those concerns
      • Profiles
        • Seven papers on EWG agenda for the topic
        • Herb has reached out to implementers for opinions
          • Aaron and Erich responded to Herb, basically saying “patches welcome” and explaining what our usual criteria are for extensions
        • Corentin (and others) have severe concerns with the current proposal
        • Seems like it should have missed the train for C++26 anyway
        • Paper steps directly into QoI decisions
      • Expansion statements (aka template for)
        • Paper came from 2019 and has sat in Core since then
        • No implementation concerns
        • It makes reflection easier (improved metaprogramming capabilities)
      • ‘offsetof’ Should Be A Keyword in C++26
        • Significant potential to break existing code due to folks relying on offsetof being a macro
        • Doesn’t solve the underlying problem of modules not working well with macros
        • Corentin: could we define it as a language-level construct that appears to be a macro
        • Hubert: that doesn’t actually solve the problem, still has issues with system headers
        • Corentin: do we still need offsetof given that we have reflection?
      • P2434R3 Nondeterministic pointer provenance
        • In Core, won’t be stopped unless failing plenary
        • We don’t think we can implement fully, LLVM plan is to take the parts we can take but otherwise ignore the paper and not worry about non-conformance
        • Has big questions around one-past-the-end pointers and neighboring locals; unsure the impacts when applying launder-like operations in the IR (i.e., built-in to generate new pointer-type value) all over the place
        • Joshua: P2434 is even more insane than TS 6010
        • Same concerns and approach with TS 6010 regarding optimization impacts
        • Hubert: unlikely to be able to stall in Core based on implementation concerns; so long as Core can get through the wording, it will show up
  • WG14 meetings Feb 24-28 (Graz, Austria)
    • 0 is no longer a null pointer constant
      • Is this even deployable?
    • _Optional qualifier
      • Applies to pointee instead of pointer, which is bad
      • Author repeatedly comes to the committee
    • Forward-declared parameters
      • Yeoul Na is going to bring a paper about counted_by attribute
  • Area Team voting happening: Reminder: Area Team Elections are in progress!

Round Table

  • Corentin will need help with pack indexing Itanium ABI changes he’s working on; hasn’t gotten much feedback from John and Richard for the strategy. Wants to get it done for Clang 21.
  • Hubert: P3006 launder less; seems to only have an effect on strict vtable pointers in Clang. We’re the only implementation impacted, but that feature has been non-conforming since Core made changes to union member access. We should see whether we can salvage that by doing the auto launder.

Meeting Agenda - Jan 15, 2025

Agenda

  • Branch date for LLVM 20 is Jan 28
    • CWG2369 causes problems for us [Clang] Reapply CWG2369 "Ordering between constraints and substitution" by zyn0217 · Pull Request #122423 · llvm/llvm-project · GitHub , we could follow GCC’s behavior but that’s non-conforming because they don’t issue a diagnostic; if there was a diagnostic, it would be conforming.
    • Could put in C++26 mode but Hubert thinks it makes more sense to implement as a DR instead. Could do it temporarily, but that sends the wrong intent.
    • Will hold off on landing this for 20, look at doing it for 21+.
    • Would be nice to fix constexpr unknown references and pointers for 20. Shafik is looking into getting it across the finish line, but it seems hairy. Going to try to get back on it soon; if we can get it in 20, great, but it’s at risk.
    • We could land with the diagnostic issue after the branch and fix the diagnostic issues. Shafik thinks this may land/revert a few times before we get it right. Corentin would prefer we get this in because of how many issues this will resolve.
    • Going to try to land this week so we can get early testing and then consider reverting before the branch if necessary.
  • WG21 meetings Feb 10-15 (Hagenberg, Austria)
  • WG14 meetings Feb 24-28 (Graz, Austria)
  • Reflection proposal (P2996)
    • Reflecting over parts of lambdas may still have some concerns (conversion functions, captured copies)
    • Asking to split define_aggregate out: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3569r0.pdf
    • Want to avoid a situation like <=> where we have long-tail of DRs that break users
    • This also impacts the “annotations” proposal: Annotations for Reflection
    • It’d be nice for us to have a somewhat consistent position as a community for folks who will be at the C++ meetings
    • Annotations proposal does not specify when to substitute or instantiate arguments, which seems broken
    • Reflecting on private members cause some discomfort but has some valid use cases, but access context paper makes it a bit better (Modeling Access Control With Reflection)
  • Some concerns around constexpr coroutines, but those concerns may be shared with other implementations
  • Also concerns around safety profiles (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3081r1.pdf), have a rebuttal paper (The Plethora of Problems With Profiles)
  • Area Team nominations happening: Call for Nominations for LLVM Project Area Teams

Round Table

  • Aaron
    • Code reviews, RFCs, and digging out
  • Ariel
    • Frontend work mostly; wondering about whether we should be able to unregister a preprocessor callback (Aaron thinks it’s reasonable
  • Coretin
    • Mostly code reviews
  • Tue
    • bfloat16 is in C++23 but not C23, wondering why. _Float16x could be used, but may not be what people want
  • Hubert
    • Looking at the encoding conversion PR for EBCDIC; still not convinced the statefulness is handled properly, nor error handling in case of requesting an invalid conversion. Trying to descope. Stateless would make the PR easier to get through. Corentin thinks that’s a good approach.
  • Mariya
    • Working on Microsoft vector deleting destructors, far from complete though. Hopefully will have something for review in the next few weeks
  • Shafik
    • Working on unknown pointers/references, also evaluating the reflection proposal
    • Code reviews
    • New person fuzzing Clang and filing bug reports; working with them to improve signal-to-noise
  • Sohail
    • New!
  • Tony
    • Nothing to report
  • Vlad
    • DR testing
    • Lots on reflection work

Meeting Agenda - Dec 04, 2024

Agenda

  • Discussion about pragma handlers in preprocessor and parser
    • When the parser is parsing an annotation token, the lexer seems to have a token lexer rather than a regular lexer, which makes re-entering a token stream hard
    • If in a token lexer, how does one switch to the ordinary lexer without getting to the end of that stream?
    • Sounds somewhat similar to #embed
    • More similar to the way pragmas work where we inject tokens in the stream, then later parse
    • There are assertions there to disallow things like processing from a macro expansion, so it’s possible that the lexer is designed to not allow this
    • The need is to be able to insert code before the pragma gets processed; for example, inserting a #include as part of handling the pragma in the parser
    • Some pragmas need to be processed before anything gets injected, others do not, so can’t always handle it from the preprocessor by inserting the tokens there
  • Canceling the next language wg meeting in Dec due to holidays

Round Table

  • Aaron
    • Constexpr enum conversion; getting user feedback about this causing problems, especially around boost. Boost is fixed, but not in LTS releases. Unsure if we’re making changes at this point.
    • Maybe we want a more proactive liaison relationship with Boost?
    • If we can find someone we know in the Boost community (maybe Peter Dimov or Jeff Garland?), we can ask them to watch the Discourse forums for the potentially-breaking tag.
    • Working on area team elections
  • Antonio
  • Ariel
    • Downstream frontend work
  • Jannik
    • Not super active recently, started new job; some test cleanup with python 2 stuff
  • Mariya
    • Mostly busy working on downstream work, otherwise reviewing patches and cleaning up unique_ptr mess with pragma handlers
  • Shafik
    • Digging out from being away for two weeks, still catching up.
    • Continuing to track regressions (especially in the latest releases)
    • Some DFP work, going to start working on literal support
    • Unknown references and pointers PR needs to get across the finish line
  • Tom
  • Vlad
    • Mostly working on reflection discussion with paper authors
      • Has a draft which has new wording based on feedback from the committee and implementers; new wording has issues though
      • Dec 13 will have a telecon on reflection, more updates to come
    • Discussing Attributes reflection in Evolution next week
      • Aaron has implementation concerns around reflecting on attribute arguments
    • Also discussing https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p0707r5.pdf
    • Wants to get back to working on DRs in P1786
  • Ambrose
    • Mostly work outside of community
    • AST visitor refactoring PRs are up for review
      • May want a PSA about recursive AST visitors to alert the community to the change in perspective
    • Working on some issues around matrix types
  • Tue

Meeting Agenda - Nov 20, 2024

Agenda

  • Aaron has some concerns about how WG21 and Clang community interact
    • We may want to find some way to have a more consistent “voice” when reporting back to standards committees as a way to strengthen our perspective

Round Table

  • Aaron
    • Documentation and policy work (RFC, refresh clang-tools-extra)
    • Going through issues to look for 19.x regressions
  • Ambrose
    • Bugs related to function effects; hitting missed constructs
    • Code reviews
    • AST visitor changes are landing!
  • Ariel
    • Frontend work downstream
  • Mariya
    • Not much to report, code reviewing and working on internal stuff
    • Handlers for pragmas have some odd memory management behaviors with regards to unique_ptr (the pointers are… shared)
  • Tue
    • Will take a first stab at working on constexpr evaluations in LLVM and Clang sometime next year, which will enable 80-bit floats and double double types everywhere
    • Plan to expand capabilities for fixed-point types; existing functionality based on older standard, exploring implementing new functions

Meeting Agenda - Oct 16, 2024

Agenda

  • Clang regression triage
    • Most are flagged and assigned, authors are mostly on top
    • How are we marking release issues

Round Table

  • Aaron
    • C std meetings. C2Y discussions:
      • lengthof array - still waiting to be finalized, implementation shouldn’t be complex
      • Named loops - labels for loops, contentious as some didn’t like labels. Syntax may also change.
      • 0 length operations on null pointer - paper was accepted https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3322.pdf
    • LLVM Developer conference preparation
      • Governance review proposal was largely accepted, but some wording changes were requested
  • Ariel
    • APfloat - recent PR changed hierarchy, affects hexfloat, decimal float
      • Is there any easy way to find the first definition
  • Corentin
    • Some code reviews, mostly working on WG21 papers
  • Hubert
    • Mostly working on non-frontend things
    • Did respond to a question about C compound literals and lifetime extension in C++
  • Mariia
    • Looking at some constexpr issues, may need to refactor some of the code around the constexpr evaluator; not working quite right for C23 constexpr
    • Clang’s diagnostic behavior is inconsistent when run from multiple threads, but GCC gives pretty clear output for the case and Clang emits the diagnostics interleaved (within a message and between messages). Trying to see what can be done. Behavior may have changed around Clang 17 with refactorings done to the diagnostics engine
  • Nick
    • libc folks really need _Float16 and _Float128 to work
    • Tom was helping the original author of those; doesn’t know if the author was planning to work on _Float128 or not ([Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. by codemzs · Pull Request #78503 · llvm/llvm-project · GitHub)
    • Default initialization of static unions only initializing the first member, not the full object
    • Shafik
      • Working on Clang 19 regressions; several on Matheus and a couple on Krystian and couple that seem minor but we have not found the cause one on _atomic_test_and_set and one on __builtin_assume_aligned and a new one from this morning
      • More people have been fuzzing lately and it’s caught Clang 19 regressions
        • More useful than the usual fuzzing issues
        • Maybe we want to do more fuzzing around release time to catch regressions?
        • Will talk to these folks to see if they’re planning to continue
      • Working on decimal floating point
        • Parsing and printing of _Decimal32 literals is working, planning to do a PR on it
        • Will do 64 and 128 support in subsequent PRs
      • Needs to get to unknown references in constant expressions
    • Tom
      • Mostly focused on SYCL upstreaming stuff
        • Adding a new attribute; questions about how attributes contribute to SFINAE, overloading, etc
    • Vlad
      • Continuing to work on DR tests for P1797, getting into cross-TU testing and trying to establish good precedents for how to write those kind of DR tests using module
        • Has some difficulties with -verify= with multiple Clang invocations
      • Looking at needs-reduction issues to help with those

Meeting Agenda - Oct 2, 2024

Agenda

  • 19.1.1 release happened last week. Looking in to 19 regressions.
  • CI fallout, patch to libc++ broke Clang CI. Will continue to run libc++ tests. Working now, but was broken over the weekend.

Round Table

Meeting Agenda - Sept 18, 2024

Agenda

  • Clang 19 released. Congratulations!
  • Clang 20 - possible deprecation of little used tools

Round Table

  • Aaron
    • Removed clang rename tool, was unmaintained and superceded by clangd.
    • Posted PR to remove clang pseudo.
    • Removed render script support, 3 years of deprecation
    • Switch from code owners to maintainers. Will follow with call for volunteers for maintainers.
    • Will be OOO for C standards and vacation, back on Oct 7
  • Ariel
    • Mostly working downstream
  • Corentin
    • Mostly working on C++ standardization
    • Some reviews, looking at some PRs
    • Have a tool called sanitizer coverage, propose should be renamed to coverage sanitizer. Would be helpful to have better documentation. Have posted a PR, suggest that we write an RFC.
  • Hubert
  • Shafik
    • Issues have slowed down a bit
    • Code reviews. Would be nice to have more in depth summaries in PRs, rather than just link to issues. Would be helpful to have better git logs.
    • DFP - parsing and printing out literals, has been a bit more involved than expected.
  • Yuxuan
    • C++ coroutine language extensions to do better heap ellison. Work has landed, but would benefit from greater feedback.
    • Fixing bugs across the stack.

Meeting Agenda - Sept 04, 2024

Agenda

  • Clang 19 release
    • rc4 is happening, final is expected after this (final should be in two weeks)
    • only backport incredibly safe fixes
    • no reports about sized deallocations, which is nice
  • Itanium ABI issues
    • Have bugs we can’t fix because we’re waiting on Itanium ABI decisions
    • How do we move forward?
    • John McCall and Richard Smith would be the folks to talk to
    • Corentin will work with Aaron, Shafik, and Vlad to send an email to find out how to get decisions unstuck in Itanium ABI lists
    • De facto standards may work as a stopgap
  • Maintainers RFC
    • Hopefully will call consensus sometime in the next week or two
    • Will start working on filling out the maintainers file for Clang (and other projects too)

Round table

  • Aaron
    • Code reviews, focusing on release candidate stuff
    • RFC reading and responding
    • WG14 and WG21 papers, WG14 meeting coming up at end of month
  • Ambrose
    • nonblocking attribute PRs are close to done, needs another set of eyes
    • bounds safety PRs, need help taking it over
    • Aaron will ask Erich if he can help on these
    • may be out for the next weeks/month
  • Ariel
    • Mostly working on downstream frontend stuff
  • Corentin
    • Lots of bug fixing
    • Still fighting source_location and consteval
      • Aaron is shocked. SHOCKED
      • Name of a function in a function template is sort of dependent, sort of not.
    • WG21 work for trivial location and contracts
    • Partial ordering of template template parameters is not in a good state; a lot of core issues and specification issues that need to be resolved; Corentin will send an email to Aaron and Erich about the concerns and what potential solutions are
  • Jannick
    • Working on clang python bindings (typing and refactoring)
    • Vlad and Jannick may come to Aaron’s office hours to discuss some issues in this area (the 10am ET hours)
  • Mariya
    • Coming back from vacation
    • Looking at improved enumerators in C23, Aaron will get on those reviews ASAP
  • Nikolas
    • Just listening
  • Shafik
    • Coming back from vacation
    • Working on issue triage
    • Working on initial DFP work
      • Ariel has a PR for APFloat formatting, will ping Shafik and Tom
    • Has to work on unknown references and pointers; needs more tests, but should be mostly ready to land
    • Code reviews
  • Tom
    • Working mostly in downstream (SYCL work that may come upstream)
    • Working on a fix for MSVC compatibility with include paths
      • Changes will be contingent on -fms-compatibility instead of driver target; is that okay?
  • Vlad
    • Back on P1787R6 on name lookup, writing tests for core issues regarding declaration matching

Meeting Agenda - Aug 21, 2024

Agenda

  • Clang 19 release
    • Will there be another RC, or will RC3 be the last one? Still waiting on feedback, but so far no release blockers have been identified. Raise with Aaron if there is anything that should be considered.

Round table

  • Aaron
    • reviewing/writing RFCs
    • Some code reviews
    • WG14 paper writing, in preparation for Sept meetings
    • Waiting on the resolution of the maintainer discussion, likely some time in September. Will poll the existing maintainers on agreement
    • Hoping to converge on the governance model in advance of the US developer meeting
  • Ambrose
    • Variadic friends, got that merged ~week ago
    • Opened PR for AST visitor refactor, waiting on comments. Some compile time regressions to be investigated.
    • Code reviews/issues
    • NFC PR was reviewed and approved. Several other old PRs have been approved but not merged, question whether to ping authors. Recommend to ping authors, can decide what to do with them if no response.
  • Ariel
    • Working mostly on downstream FE work
    • PR for upstreaming Hexfloat work
  • Corentin
    • Code reviews
    • PR open
  • Janik
    • Recently contribution to Clang-Python bindings, introducing type bindings
  • Shafik
    • Unknown references and pointers, working through some of the failures. Will wait until after Clang19 to land, fundamental change.
    • Catching up on reviews.
  • Vlad

Meeting Agenda - Aug 07, 2024

Agenda

Round Table

Meeting Agenda - Jul 17, 2024

Agenda

  • Clang 19, what is left to do before we branch? (happens next Tue)
    • GitHub issue tracking to see what regressions exist for Clang 19, Shafik will put it together; Vlad mentioned we have milestones we could tie it to for release managers
    • Not many regressions known so far, expect to see more when rc1 is cut
    • Constexpr on unknown references?
      • Shafik is working on it, almost there, but we’ll see
    • Vlad will be landing -Ofast deprecation today
  • Sized deallocation, any new feedback?
    • It seems to have stuck and not needed a revert; disabled for some targets where it was an issue
    • rc1 will be the real test
  • CI?

Round Table

  • Aaron
    • Working on regression with alignas in C23
  • Antonio
  • Ariel
    • Started upstreaming for hex float work, to support what needs to go into APFloat
    • Next up will be actual hex float changes
  • Corentin
    • Code reviews, looking at issues and regressions, preparing for the branch
    • Started merging PRs on behalf of folks where it was accepted but not merged
    • Started to work on constexpr placement new for C++26, requires pointer interconvertibility support which may be hard/impossible for us to implement. May need to go back to Core, could implement via “same type” in the meantime.
  • Hubert
    • Mostly working on internal stuff
    • Fold expressions patch came up and landed but there may be issues with the C++ specification discovered during that work. Will check on that and verify the behavior of the patch against those cases. C++26 feature, not been applied as an extension to earlier modes for risk of breaking code.
    • Will get back to constexpr math patch when getting out from under internal stuff
  • Mariya
    • Mostly working on #embed bugs, looking at GCC test from Jakub
    • Worked on _BitInt codegen, landed this week
      • Need to go through open issues that could be closed now
      • Corrected the alignment concerns with _BitInt(128) and __int128_t
      • Hubert said some platforms don’t have a 16 byte fundamental alignment in all contexts, so malloc may not give you a 16-byte aligned location. This is an issue for the C committee to address. Same issues with max_align_t as intmax_t.
  • Shafik
    • Working on unknown references in constexpr, adding new tests and ensuring old issues are handled. At least one bug remains; may not make the Clang 19 branch.
    • Doing more code review as well as triaging issues (esp looking for good first issues). Leaves details about how to resolve the issue when it’s marked good first issue.
  • Vlad
    • Completed research in bug database; 1200 issues left to tag and then everything will have a correct label; should make it easier to filter for Clang bugs and be confident we got them all.
      • Can we introduce a new label and use that to basically say “untriaged” and then only put the real label on as we triage.

Meeting Agenda - Jul 03, 2024

Agenda

Round Table

  • Aaron
    • C99 status is now complete
    • Started adding C2y support
  • Ambrose
    • Working on improving speed of recursive AST visitors
    • About 2-3% compile time improvement
    • Allowing raw string literals in C, needs one small fix and is ready to merge
    • Disallow explicit object parameters in more contexts, mostly done but needs final review
  • Ariel
    • Working DWARF issues on their end, will upstream some of that work
    • Started to upstream hexfloat support, breaking into multiple small changes
  • Hubert
    • Was in WG21 meetings last week
      • Committee was looking into 128-bit integers as a formally extended integer type; still in early stages – multiple platforms impacted due to C committee wording due to fundamental alignment requirements with max_align_t. Wording C is probably subject to implementation veto due to existing practice.
      • EWG forwarded non-deterministic pointer provenance to CWG. A bit easier to consume than TS 6010, but there are required changes to the compiler for the C++ changes. No implementation experience with it so far. Would like to chat with Aaron about it more offline. Shafik said there were fine points on the proposal that haven’t been resolved, so round-tripping integers and pointers may not have a final conclusion. Hubert said there were disagreements about what can be assumed about existing implementations and whether or not the direction was good for things like CHERI or AS400 in terms of hardware capabilities, but in terms of optimization, he’s not sure there were solid objections. We need to understand how conforming CHERI (and similar) are (or not) in terms of the status quo. There may be two different models for memcpy behavior between “assignment” and C/C++ memcpy. C++ paper does not affect pointer arithmetic. Should we go back to the committee with more information regarding conformance for AS400/CHERI (assuming those are not actually conforming under the new model)? Potential confusion between people (across the C and C++ committees) over how “direct” the roundtripping needs to be. Key difference between C and C++ models will be storage (C) versus objects (C++).
    • Might get back to constexpr math code review when chance comes up
  • Mariya
    • Posted a PR for improving embed
    • Was on vacation
  • Shafik
    • PR for unknown references in pointers in constexpr; needs some modifications for memory management. Will get back to this at some point.
    • Working on DFP with Tom, initial changes to APFloat to start getting DFP testable in the AST; once that’s one, can start working on basic literal support.
    • Was in WG21 meetings last week
      • Reflection was seen in Core; big paper with lots of changes. Identified an ambiguous parse issue with use of ^ as an operator; coordinated with folks to ensure that issue is addressed. No decision made for the replacement syntax yet.
      • Aaron asked about ramifications of reflections for standard library types like std::initializer_list and std::type_info. The concern is that these have unspecified mechanisms for construction that an implementation might not want to expose. Tom followed up with the LEWG chair, Inbal, to ask if this was discussed in LEWG. Inbal stated that it was and that no promises are made regarding the stability of implementation details or what is exposed from the standard library. She provided assurance that there will be blanket wording that states that intent.
  • Tom
    • No updates, was in WG21 meetings last week
    • Will work on DFP hopefully sometime this month
  • Vlad
    • Was also in WG21 meetings last week (remote)
    • Moved documentation from implementation files to header files so that tooling can see it more consistently.
    • Features we’d like to see in Clang 19
      • Sized deallocation seems to be causing problems (now disabled by default for AIX and MinGW, causing concerns for downstreams). Should the compiler generate the symbols (and mark them as weak) instead? Might make transitioning easier on users to do that. In particular, under certain linkage models, having the default sized deallocation symbols in the library means that calls to them will result in the library implementation calling its default non-sized versions of the symbols (instead of the user’s replacement). This happens when run-time linking is not enabled or when the user fails to make the user replacement visible to run-time linking. Under the case where sized deallocation is not enabled, the user replacement is effective at least for calls from the same load module; with sized deallocation enabled, calls that use the sized deallocation function will (for affected builds) fail to call the user replacement. Possible migration guidance for users is to provide a replacement sized deallocation function whenever they provide a non-sized one. (Past attempts to deploy sized deallocation: ⚙ D8467 C++14: Disable sized deallocation by default due to ABI breakage, ⚙ D112921 [clang] Enable sized deallocation by default in C++14 onwards)

Meeting Agenda - Jun 05, 2024

Agenda

  • What goes into Clang 19, what will miss the deadline?
    • July 23 is cutoff date
    • Will be losing reviewers (WG14 and WG21 meetings, time off, etc)
    • Embed should likely land this week/next, should be explicitly stated somewhere that it’s subject to improvements that may change things like command line flags
    • Do we need to do anything special for crash reports within embed itself
      • Might want the driver to say that the crash report cannot be automatically generated; could do base64 encoded data for the embed data, etc
    • Core issue fixes (Vlad will find links: https://github.com/llvm/llvm-project/pull/92957, https://github.com/llvm/llvm-project/pull/92527)
    • Sized deallocation is still causing problems (https://github.com/llvm/llvm-project/pull/90373)
    • Should ask Chuanqi whether there are outstanding modules issues we need to get resolved before we ship
  • Ofast
    • Aaron needs to call consensus and respond on the RFC
  • __restrict

Round Table

  • Aaron
    • Monthly maintainer meetings starting soon (today); may ask for help from folks to unblock work elsewhere in the community
    • WG14 meetings next week, code review time is limited
  • Vlad
    • Removing try_compile checks to improve build times, trying to figure out what platforms we have custom checks for but don’t have test coverage for, etc
    • Continuing to split up Sema.h
  • Mariya
    • Working on _BitInt codegen issues
    • Did a lot of work on embed, got it almost across the finish line
    • Might be situations regarding macro expansions that C requires that may not be intentional; SG22 will convene as needed to discuss
  • Corentin
    • Lots of code reviews, not much else to report
  • Ambrose
    • nolock/noalloc PR has been approved, but looking for a second set of eyes to review it (https://github.com/llvm/llvm-project/pull/84983; Aaron will help there and also poke Erich)
    • RecursiveASTVisitor may be negatively impacting compile times because of CRTP, investigating using virtual functions to improve the situation
  • Hubert
  • Tony
    • Not much to report
  • Ariel
    • Working on DWARF issues
    • Still working on hexfloat, want to get a PR out in the next few weeks (going through internal review)

Meeting Agenda - May 15, 2024

Agenda

Round Table

  • Aaron
    • Focus on #embed review, hopefully will be approved in the next week
    • C standards meeting week of June 10, some papers to prepare
  • Ariel
    • DWARF issues
    • Char conv for hexfloat. Still in internal review.
  • Hubert
  • Mariia
  • Shafik
    • Unknown references in pointers, spent time on this
    • Bug screening has been very busy, many bugs being reported. Higher level of crashes.

Meeting Agenda - May 1, 2024

Agenda

Round Table

  • Ambrose
    • Looking over PRs
  • Ariel
    • Preparing hexfloat PR for upstreaming, RFC has been out for quite some time
  • David
    • Backing up Hubert, participating in the DFP discussions
  • Michael
  • Shafik
    • unknown references and pointers implementation
    • Bug screening
  • Tony
    • Planning to work on C23 N3006 underspecified declarations
      • Patch will likely land end of year
    • Investigating a Clang bug, but think it’s likely user error
  • Tom

Meeting Agenda - April 17, 2024

Agenda

  • “Memory safety” of C++
    • Hubert introduced the topic; Herb has a blog on this at https://herbsutter.com/2024/03/11/safety-in-context.
    • Aaron asked about the objectives for this discussion.
    • Hubert is curious if implementors are concerned about safety.
    • Aaron replied that users are lamenting the growing complexity of the language and that new features face adoption challenges. Users are saying they use Rust when they want memory safety and C++ when they want to be close to the hardware.
    • Aaron noted that limited funding for non-memory-safe language might have a chilling effect going forward.
    • Ariel asked about what memory safety means in this context.
    • Hubert replied that Herb’s blog post discusses a particular notion.
    • Shafik asserted that we don’t have to define it that well to have a useful conversation.
    • Hubert explained that there are various conversations going on about how to make C++ safer; e.g., run-time checks. The government seems to be pointing to just eliminating such concerns in the first place.
    • Hubert stated there are specific reasons for wanting to use C and C++; e.g., for low latency real-time programming. The memory safety concerns are forcing us to re-make the business case for C++.
    • Corentin replied that implementors can respond more quickly than WG21 can. There are things that we can do in the library to check preconditions or in the language to address uninitialized memory.
    • https://www.phoronix.com/news/GCC-fhardened-Hardening-Option
    • https://github.com/llvm/llvm-project/pull/78763
    • https://discourse.llvm.org/t/rfc-c-buffer-hardening/65734
    • Corentin mentioned that ClangIR might provide means to do more checking at a higher level.
    • Shafik agreed with Corentin and argued that we should be thinking about what extensions we can offer without waiting for WG21. People can’t switch to Rust overnight, so focus is on interop; if interop improves, then switching becomes simpler, and that poses more of a risk to the future use of C++ via a slow/incremental migration.
    • Aaron noted that WG14 has a pointer provenance TS in progress. Integrating that will require changes for all implementors. We can evaluate that for performance and safety and provide feedback where there are preferential choices that can be made.
    • Shafik reported having spent time learning Rust to see how it works and consider how things it does could be applied to C++. Sean Baxter has been doing some of this.
    • Tom asked how people were thinking about Bjarne’s profile proposal.
    • Hubert replied that it effectively provides a way to write code in a safe subset of the language. The government seems to be urging everything to move to safe languages; a response is that new features could improve safety without requiring a wholesale migration.
    • Shafik opined that these piecemeal approaches downplay the significance of the issues.
    • Corentin asserted a responsibility to existing users to preserve their investments and not require a complete migration to another language. If the industry has had its time and it is time to move, that is ok. My goal is not to ensure C++ survives forever; though we might have to change jobs :slight_smile:
    • Hubert argued that there are code bases that will never migrate and that are (hopefully) at a steady state.
    • Aaron agreed; there is plenty of code that is used and minimally maintained.
    • Aaron stated that providing tools that identify problems helps to preserve investment.
    • Shafik commented that an approach used is to provide a hardened surface that protects the (softer) interior.
    • Shafik agreed that there will be legacy code that will not be rewritten, but that we can do more for new code.
    • Aaron stated there is an implication that more code will be written than has been written; we don’t know that for sure; we might be at a COBOL moment where the focus becomes maintenance.
    • Shafik noted that we can only know that in hindsight.
    • Aaron replied that there is some information present in the C++ Foundation surveys or language use indexes.
    • Ariel asked, if we’re at peak C++ usage, then why so much energy in producing new C++ standards so frequently.
    • Aaron replied that there are ISO requirements for completion of work items and noted that some participants treat WG21 as an opportunity.
    • Aaron opined that he doesn’t think we’re at peak use yet, but might be on the way there.
    • Ariel pondered whether making the language more complicated discourages adoption.
    • Hubert acknowledged the concern, but noted that much of the core language additions are intended to enable powerful libraries that don’t require extensive knowledge of the language.
    • Ariel noted that some of the new library functionality is complicated. Is C++ going to become a language for library writers?
    • Hubert argued that, to some degree, it always has been.
    • Corentin opined that C++ isn’t necessarily becoming harder to use. Average users don’t need to be exposed to all of it.
    • Aaron reported that some concerns have been expressed about new language versions changing the meaning of existing code for previous versions due to adoption of DRs. Upgrading the compiler can have a similar effect to moving to a new language version.
    • Hubert argued that deciding what to do with DRs on a case by case basis is not particularly viable.
    • Aaron reported that, historically, Clang maintainers have followed WG21 guidance. We could do more to educate users about the ramifications of compiler upgrades.
    • Corentin stated that sanitizers find lots of issues, but adoption of them is not universal.
    • Tom jokingly suggested we could enable sanitizers by default so that users have to turn them off.
    • Aaron noted that we could enable some portions of sanitizer support.
    • Corentin pondered whether some portions of sanitizers could be made more usable in production scenarios.
    • Hubert noted this as a particular action item we can pursue; making sanitizers more usable in production.
    • Aaron suggested we could add some hardening to libc++ like Microsoft has.
    • Eric replied that some of that is happening. Libc++ previously had debug iterators, but that was removed for reasons.
    • Corentin argued for easy ways to enable precondition checking.
    • Aaron noted that we do distinguish between -std=c++ and -std=gnuc++ and we could add -fhardened or similar as part of the extended mode. We could add a -std=clangc++ mode.
    • Hubert expressed some reluctance about that.
    • Aaron replied that we do enable some extensions in -std=gnu++ mode.
    • Eric expressed support for such a mode.
    • Eric lamented the lack of telemetry that indicates what users actually do.
    • Ariel asked for more details.
    • Eric replied that he would like to know what percentage of users are using a hardened mode for libc++.
    • Hubert expressed a preference for a different invocation name rather than a different -std mode.
    • Hubert reviewed suggested action items:
      • Sanitizers
      • Hardened modes
      • The C pointer provenance TS
    • Aaron stated that, to his knowledge, no one has investigated what changes will be required to LLVM by the pointer provenance TS.
    • Corentin lamented that we don’t have people working on LLVM for C++. For example, std::start_lifetime_as needs support, type aliasing is broken, assumptions are broken.
    • Aaron stated there are opportunities to improve how we collectively make interrelated changes to clang, LLVM, libc++.
    • Vlad stated that we don’t seem to have people working on codegen.
    • Aaron named a few people that are doing so, but that they are very busy.
    • Hubert directed discussion back to the pointer provenance TS. The TS constrains what programs are valid, but it is optional whether it enables discovery of programs that are not valid.
    • Aaron responded that the model in the TS is based on a survey of how implementations actually work and trying to identify common ground.
    • Hubert compared the C and C++ memory model rules.
    • Aaron stated that it should be possible to instrument for diagnosis.
    • Hubert asked about options to have programs fail when rules are valid.
    • Aaron responded that the TS doesn’t go into that, but implementors certainly can; the model is UB driven, so implementors can do what they like in the UB space. The model enables analysis.
    • Aaron expressed concern that such analysis might not be feasible given the way the LLVM passes work.

Round Table

  • Aaron:
    • Still working on C99 conformance testing.
  • Ambrose:
    • Still working on input from OpenCL for assume.
    • Working on the lock/nolock RFC.
    • Working on deducing this, particularly for lambdas.
    • Working on C++26 =delete(“with a message”).
  • Ariel:
    • Working on implementing charconv for hex float.
    • Getting back to upstreaming hex float support.
  • Corentin:
    • Code reviews.
    • Will probably approve the EBCDIC PR soon; Aaron will do a quick review too.
  • Eric:
    • Nothing to report.
  • Hubert::
    • There is an issue with vector literals like those used in Power. Conversion from a class type doesn’t work in Clang; there is ambiguity. Clang asserts “unimplemented”. This will need some help from OpenCL folks.
  • Mariya:
    • Made some progress on #embed.
  • Shafik::
    • I am busy but not a lot of progress on specifics. Bug screening is very busy.
  • Tom:
    • Trying to do DFP stuff, but progress has been slow.
  • Vlad:
    • Put out a patch to split Objective-C out of the existing Sema class.
1 Like