LLVM 21.1.0-rc1 C++ Standard Library Compatibility Issues

[chatgpt-copypasta]

ISSUE

LLVM 21.1.0-rc1's libc++ introduces template metaprogramming changes that break compatibility with large C++ codebases and C++ binding generators, specifically around std::invoke_result_t and std::basic_string_view template instantiations.

EXPECTED BEHAVIOR

LLVM 21's libc++ should maintain backward compatibility with existing C++ code patterns used in major projects, or provide clear migration paths.

STEPS TO REPRODUCE

Environment:

• LLVM 21.1.0-rc1 on macOS aarch64
• Large C++ codebase (Firefox, ~10M+ lines)
• C++ binding generator (rust-bindgen)

Template Usage Patterns That Break:

// 1. Complex invoke_result_t instantiations
template<typename ResolveFunction, typename ResolveValueT>
struct Promise {
    using resolve_result = std::invoke_result_t<ResolveFunction, ResolveValueT>;
};

// 2. basic_string_view in template contexts
template<typename CharT, typename Traits = std::char_traits<CharT>>
class StringProcessor {
    std::basic_string_view<CharT, Traits> view_;
};

Compilation Context:

clang++ -std=c++17 -I/opt/llvm-21.1.0-rc1/include/c++/v1 test.cpp

ATTEMPTS TO RESOLVE

Analysis of Template Changes
Compared LLVM 21 vs LLVM 19 template definitions:

LLVM 19 (Working):

template<class _Fn, class... _Args>
struct invoke_result : public __invoke_result<_Fn, _Args...> {};

template<class _Fn, class... _Args>
using invoke_result_t = typename invoke_result<_Fn, _Args...>::type;

LLVM 21 (Problematic):

// More complex SFINAE and template parameter handling
template<class _Fn, class... _Args>
struct invoke_result : public __invoke_result<_Fn, _Args...> {
    // Additional template metaprogramming complexity
};

Impact on Binding Generators
Binding generators (bindgen, SWIG, etc.) fail because:

1. Template Parameter Extraction: Cannot resolve _CharT, _Traits, _Args in complex instantiations
2. SFINAE Patterns: More sophisticated SFINAE in LLVM 21 breaks simple template parsing
3. Nested Template Resolution: Deeply nested template hierarchies are not properly resolved

OUTCOME AND FINDINGS

Compatibility Regression
LLVM 21 introduces template metaprogramming changes that are:

1. Semantically Equivalent: Same runtime behavior as LLVM 19
2. Syntactically Different: Different template instantiation patterns
3. Tool-Breaking: Incompatible with existing C++ tooling ecosystem

Affected Template Types

1. std::invoke_result_t - Core issue in complex template instantiations
2. std::basic_string_view - Template parameter resolution problems
3. std::enable_if_t patterns - SFINAE changes break some use cases

Ecosystem Impact
This affects:

• Firefox (confirmed failing at 58% build completion)
• Other large C++ projects using binding generators
• C++ tooling ecosystem (bindgen, SWIG, etc.)

REQUESTED ACTION

Immediate (LLVM 21.1.0 stable)

1. Template Compatibility Audit: Review template metaprogramming changes for backward compatibility
2. Binding Generator Testing: Test LLVM 21 against major binding generators (bindgen, SWIG, pybind11)
3. Documentation: Document template changes that affect tooling

Long Term

1. Template Stability Policy: Consider impact on C++ tooling ecosystem when making template changes
2. Binding Generator Liaison: Coordinate with binding generator maintainers on template changes
3. Compatibility Testing: Add major C++ projects to LLVM CI for compatibility testing

Specific Technical Review
Files needing review:

• libcxx/include/type_traits (invoke_result_t implementation)
• libcxx/include/string_view (basic_string_view template patterns)
• Template SFINAE patterns that changed between LLVM 19 and 21

Questions for LLVM team:

1. Were the template metaprogramming changes intentional compatibility breaks?
2. Is there a migration path for binding generators?
3. Can template instantiation patterns be made more tooling-friendly?

Priority: This will block adoption of LLVM 21 by major C++ projects that rely on binding generators.

Note: This is not a request to revert changes, but to ensure ecosystem compatibility is considered in template metaprogramming decisions.

[androm3da]

cc @ldionne

[cor3ntin]

@rnk

[philnik777]

Could you provide a reproducer? I have honestly no idea what the problem you're trying to report is.

Edit: It sounds like you might be talking about #151028, but I really don't know.

[cor3ntin]

@philnik777 this looks AI-generated; I pinged Reid, so he his aware of those sorts of issues, and decides whether this issue follows community guidelines :)

[erichkeane]

@philnik777 this looks AI-generated; I pinged Reid, so he his aware of those sorts of issues, and decides whether this issue follows community guidelines :)

I'll note the poster's name: chatgpt-copypasta

[androm3da]

@philnik777 this looks AI-generated; I pinged Reid, so he his aware of those sorts of issues, and decides whether this issue follows community guidelines :)

I'll note the poster's name: chatgpt-copypasta

I thought it was clever self-deprecation. But looking at the other activity for this account, I'm much more suspicious.

[ldionne]

I'd be tempted to close as invalid and adopt that as a policy for anything that looks like low-quality unactionable reports. I don't know who/what generated this, but there is no reproducer and only vague claims about stuff being broken, which by the way involves internal libc++ types that we have no intention of keeping stable. I think we want to openly discourage this kind of bug reporting practice since it creates noise and increase the maintainers' burden without providing much value.

I'll sync up with @philnik777 a bit later today. FWIW, I do think that having a LLVM wide policy for this would make sense, especially since that is bound to happen more and more with the rise of AI assistance / tooling.

[rnk]

I have a draft policy that specifically bans this kind of stuff: main...rnk:llvm-project:tool-policy I'm on a rotation this week, so unfortunately I don't have much time to move it forward, but it's my top priority going forward. It's a draft, there's some things I want to tweak, so it's not a PR yet.

If I take the issue intro seriously, yes, sure, source compatibility is a project goal for libc++, but I don't see any evidence worth spending time on that we could take action on.