mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-28 16:36:09 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/clang/docs/ReleaseNotes.rst

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

692 lines
30 KiB
ReStructuredText
Raw Normal View History

[docs] Remove hard-coded version numbers from sphinx configs This updates all the non-runtime project release notes to use the version number from CMake instead of the hard-coded version numbers in conf.py. It also hides warnings about pre-releases when the git suffix is dropped from the LLVM version in CMake. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D112181
2022-02-01 23:13:01 -08:00
===========================================
Clang |release| |ReleaseNotesTitle|
===========================================
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
.. contents::
:local:
:depth: 2
Written by the `LLVM Team <https://llvm.org/>`_
[docs] Remove hard-coded version numbers from sphinx configs This updates all the non-runtime project release notes to use the version number from CMake instead of the hard-coded version numbers in conf.py. It also hides warnings about pre-releases when the git suffix is dropped from the LLVM version in CMake. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D112181
2022-02-01 23:13:01 -08:00
.. only:: PreRelease
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
[docs] Remove hard-coded version numbers from sphinx configs This updates all the non-runtime project release notes to use the version number from CMake instead of the hard-coded version numbers in conf.py. It also hides warnings about pre-releases when the git suffix is dropped from the LLVM version in CMake. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D112181
2022-02-01 23:13:01 -08:00
.. warning::
These are in-progress notes for the upcoming Clang |version| release.
Release notes for previous releases can be found on
Fix broken link on Clang documentation page While browsing the latest [clang manual](https://clang.llvm.org/docs/ReleaseNotes.html), I came across this warning and clicked, but it leads to a broken page, apparently because it's missing the trailing `/`. Seems to be the only place where it's missing in the whole of LLVM monorepo. {F26690053} {F26690057} Reviewed By: brenoguim, royjacobson Differential Revision: https://reviews.llvm.org/D145047
2023-03-05 00:56:15 +02:00
`the Releases Page <https://llvm.org/releases/>`_.
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
Introduction
============
This document contains the release notes for the Clang C/C++/Objective-C
[docs] Remove hard-coded version numbers from sphinx configs This updates all the non-runtime project release notes to use the version number from CMake instead of the hard-coded version numbers in conf.py. It also hides warnings about pre-releases when the git suffix is dropped from the LLVM version in CMake. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D112181
2022-02-01 23:13:01 -08:00
frontend, part of the LLVM Compiler Infrastructure, release |release|. Here we
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
describe the status of Clang in some detail, including major
improvements from the previous release and new feature work. For the
general LLVM release notes, see `the LLVM
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
documentation <https://llvm.org/docs/ReleaseNotes.html>`_. For the libc++ release notes,
see `this page <https://libcxx.llvm.org/ReleaseNotes.html>`_. All LLVM releases
may be downloaded from the `LLVM releases web site <https://llvm.org/releases/>`_.
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
For more information about Clang or LLVM, including information about the
latest release, please see the `Clang Web Site <https://clang.llvm.org>`_ or the
`LLVM Web Site <https://llvm.org>`_.
Add a "Potentially Breaking Changes" section to the Clang release notes Sometimes we make changes to the compiler that we expect may cause disruption for users. For example, we may strengthen a warning to default to be an error, or fix an accepts-invalid bug that's been around for a long time, etc which may cause previously accepted code to now be rejected. Rather than hope users discover that information by reading all of the release notes, it's better that we call these out in one location at the top of the release notes. Based on feedback collected in the discussion at: https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-implicit-function-declaration/65213/ Differential Revision: https://reviews.llvm.org/D133771
2022-09-15 07:29:49 -04:00
Potentially Breaking Changes
============================
These changes are ones which we think may surprise users when upgrading to
Clang |release| because of the opportunity they pose for disruption to existing
code bases.
[CMake] Change GCC_INSTALL_PREFIX from warning to fatal error (#85891) unless USE_DEPRECATED_GCC_INSTALL_PREFIX (temporary escape hatch) is set. Setting GCC_INSTALL_PREFIX leads to a warning for Clang 18.1 (#77537) and will be completely removed for Clang 20. Link: discourse.llvm.org/t/add-gcc-install-dir-deprecate-gcc-toolchain-and-remove-gcc-install-prefix/65091 Link: discourse.llvm.org/t/correct-cmake-parameters-for-building-clang-and-lld-for-riscv/72833
2024-03-20 22:45:38 -07:00
- Setting the deprecated CMake variable ``GCC_INSTALL_PREFIX`` (which sets the
default ``--gcc-toolchain=``) now leads to a fatal error.
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
C/C++ Language Potentially Breaking Changes
-------------------------------------------
Reland: [clang][ExprConstant] fix __builtin_object_size for flexible array members As reported by @kees, GCC treats __builtin_object_size of structures containing flexible array members (aka arrays with incomplete type) not just as the sizeof the underlying type, but additionally the size of the members in a designated initializer list. Fixes: https://github.com/llvm/llvm-project/issues/62789 Reviewed By: erichkeane, efriedma Differential Revision: https://reviews.llvm.org/D150892
2023-05-23 14:41:43 -07:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
C++ Specific Potentially Breaking Changes
-----------------------------------------
Reapply "[Clang][Sema] Diagnose function/variable templates that shadow their own template parameters (#78274)" (#79683) Reapplies #78274 with the addition of a default-error warning (`strict-primary-template-shadow`) that is issued for instances of shadowing which were previously accepted prior to this patch. I couldn't find an established convention for naming diagnostics related to compatibility with previous versions of clang, so I just used the prefix `ext_compat_`.
2024-03-04 09:18:21 -05:00
- Clang now diagnoses function/variable templates that shadow their own template parameters, e.g. ``template<class T> void T();``.
This error can be disabled via `-Wno-strict-primary-template-shadow` for compatibility with previous versions of clang.
[Release Notes] [C++20] [Modules] Summarize modules related change to the release note for clang 18 Given clang18 is going to be released, this patch collects the modules related change to release notes to make users have a clear vision for modules.
2024-01-19 15:08:39 +08:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
ABI Changes in This Version
---------------------------
[clang][MSVC] Correct mangling of thread-safe static initialization variables. (#85300) Static local variables with dynamic initializers depend on implicitly defined guard variables to synchronize thread-safe initialization. These guard variables may have external linkage and therefore require a stable name for linkage purposes. The Microsoft ABI assigns these variables a local name of '$TSS' followed by a discriminator and mangles them as a static local variable of type 'int'. Previously, the '$TSS<discriminator>' portion of the name was not registered as a back reference candidate and this resulted in incorrect back references for enclosing class and/or namespace scopes that might be referenced in the signature of the enclosing function. This change adds the previously missing back reference registration. This matches the mangling performed by MSVC and resolves incompatibilities when inline functions with static local variables are inlined across DLL boundaries. This is an ABI change and has the potential to cause backward compatibility issues with previous Clang releases. Fixes #83616
2024-03-15 16:12:19 -07:00
- Fixed Microsoft name mangling of implicitly defined variables used for thread
safe static initialization of static local variables. This change resolves
incompatibilities with code compiled by MSVC but might introduce
incompatibilities with code compiled by earlier versions of Clang when an
inline member function that contains a static local variable with a dynamic
initializer is declared with ``__declspec(dllimport)``. (#GH83616).
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
[clang] Correct Microsoft mangling of lifetime extended temporary objects. (#85529) Lifetime extended temporary objects that are bound to references with static storage duration may have external linkage and therefore require mangled symbol names. Clang uses an extension of the Microsoft ABI to give these symbols an implicit name of '$RT' followed by a discriminator and then mangles them similarly to the variable they are bound to. Clang's mangling scheme differs from the one used by MSVC. Previously, the `$RT<discriminator>` portion of the name was not registered as a back reference candidate and this resulted in incorrect back references for enclosing class and/or namespace scopes that might be referenced in the type of the object. This is an ABI change and has the potential to cause backward compatibility issues with previous Clang releases. Since MSVC uses a different mangling scheme, this change does not affect compatibility with MSVC. This fixes one of the name mangling concerns reported in #85423.
2024-03-25 10:39:05 -04:00
- Fixed Microsoft name mangling of lifetime extended temporary objects. This
change corrects missing back reference registrations that could result in
incorrect back reference indexes and suprising demangled name results. Since
MSVC uses a different mangling for these objects, compatibility is not affected.
(#GH85423).
[AST] Only dump desugared type when visibly different (#65214) These are an artifact of how types are structured but serve little purpose, merely showing that the type is sugared in some way. For example, ElaboratedType's existence means struct S gets printed as 'struct S':'struct S' in the AST, which is unnecessary visual clutter. Note that skipping the second print when the types have the same string matches what we do for diagnostics, where the aka will be skipped.
2023-10-26 19:28:28 +01:00
AST Dumping Potentially Breaking Changes
----------------------------------------
[Docs] Add release note about Clang-defined target OS macros (#79879)
2024-01-30 09:30:20 -08:00
Clang Frontend Potentially Breaking Changes
-------------------------------------------
[Clang][NFC] Remove TemplateArgumentList::OnStack (#79760) This patch removes on-stack `TemplateArgumentList`'s. They were primary used to pass an `ArrayRef<TemplateArgument>` to `Sema::getTemplateInstantiationArgs`, which had a `const TemplateArgumentList*` parameter for the innermost template argument list. Changing this parameter to an `std::optional<ArrayRef<TemplateArgument>>` eliminates the need for on-stack `TemplateArgumentList`'s, which in turn eliminates the need for `TemplateArgumentList` to store a pointer to its template argument storage (which is redundant in almost all cases, as it is an AST allocated type).
2024-02-01 11:50:50 -05:00
- Removed support for constructing on-stack ``TemplateArgumentList``s; interfaces should instead
use ``ArrayRef<TemplateArgument>`` to pass template arguments. Transitioning internal uses to
``ArrayRef<TemplateArgument>`` reduces AST memory usage by 0.4% when compiling clang, and is
expected to show similar improvements on other workloads.
[Docs] Add release note about Clang-defined target OS macros (#79879)
2024-01-30 09:30:20 -08:00
[C23] Do not diagnose binary literals as an extension (#81658) We previously would diagnose them as a GNU extension in C mode, but they are now a feature of C23. The -Wgnu-binary-literal warning group no longer controls any diagnostics as this is no longer a GNU extension. The warning group is retained as a noop to help avoid "unknown warning" diagnostics. This also adds the companion compatibility warning which existed for C++ but not for C. Fixes https://github.com/llvm/llvm-project/issues/72017
2024-02-14 09:08:28 -05:00
- The ``-Wgnu-binary-literal`` diagnostic group no longer controls any
diagnostics. Binary literals are no longer a GNU extension, they're now a C23
extension which is controlled via ``-pedantic`` or ``-Wc23-extensions``. Use
of ``-Wno-gnu-binary-literal`` will no longer silence this pedantic warning,
which may break existing uses with ``-Werror``.
[docs] Remove hard-coded version numbers from sphinx configs This updates all the non-runtime project release notes to use the version number from CMake instead of the hard-coded version numbers in conf.py. It also hides warnings about pre-releases when the git suffix is dropped from the LLVM version in CMake. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D112181
2022-02-01 23:13:01 -08:00
What's New in Clang |release|?
==============================
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
Some of the major new features and improvements to Clang are listed
here. Generic improvements to Clang as a whole or to its underlying
infrastructure are described first, followed by language-specific
sections with improvements to Clang's support for those languages.
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
C++ Language Changes
--------------------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
C++20 Feature Support
^^^^^^^^^^^^^^^^^^^^^
[Clang] Fix Unevaluated Lambdas Unlike other types, when lambdas are instanciated, they are recreated from scratch. When an unevaluated lambdas appear in the type of a function, parameter it is instanciated in the wrong declaration context, as parameters are transformed before the function. To support lambda in function parameters, we try to compute whether they are dependant without looking at the declaration context. This is a short term stopgap solution to avoid clang iceing. A better fix might be to inject some kind of transparent declaration with correctly computed dependency for function parameters, variable templates, etc. Fixes https://github.com/llvm/llvm-project/issues/50376 Fixes https://github.com/llvm/llvm-project/issues/51414 Fixes https://github.com/llvm/llvm-project/issues/51416 Fixes https://github.com/llvm/llvm-project/issues/51641 Fixes https://github.com/llvm/llvm-project/issues/54296 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D121532
2022-03-12 20:49:01 +01:00
[C++20] [Modules] Don't perform ODR checks in GMF Close https://github.com/llvm/llvm-project/issues/79240. See the linked issue for details. Given the frequency of issue reporting about false positive ODR checks (I received private issue reports too), I'd like to backport this to 18.x too.
2024-01-29 11:42:08 +08:00
- Clang won't perform ODR checks for decls in the global module fragment any
more to ease the implementation and improve the user's using experience.
[C++20] [Modules] Introduce -fskip-odr-check-in-gmf (#79959) Close https://github.com/llvm/llvm-project/issues/79240 Cite the comment from @mizvekov in //github.com/llvm/llvm-project/issues/79240: > There are two kinds of bugs / issues relevant here: > > Clang bugs that this change hides > Here we can add a Frontend flag that disables the GMF ODR check, just > so > we can keep tracking, testing and fixing these issues. > The Driver would just always pass that flag. > We could add that flag in this current issue. > Bugs in user code: > I don't think it's worth adding a corresponding Driver flag for > controlling the above Frontend flag, since we intend it's behavior to > become default as we fix the problems, and users interested in testing > the more strict behavior can just use the Frontend flag directly. This patch follows the suggestion: - Introduce the CC1 flag `-fskip-odr-check-in-gmf` which is by default off, so that the every existing test will still be tested with checking ODR violations. - Passing `-fskip-odr-check-in-gmf` in the driver to keep the behavior we intended. - Edit the document to tell the users who are still interested in more strict checks can use `-Xclang -fno-skip-odr-check-in-gmf` to get the existing behavior.
2024-02-01 13:44:32 +08:00
This follows the MSVC's behavior. Users interested in testing the more strict
behavior can use the flag '-Xclang -fno-skip-odr-check-in-gmf'.
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
(#GH79240).
[C++20] [Modules] Don't perform ODR checks in GMF Close https://github.com/llvm/llvm-project/issues/79240. See the linked issue for details. Given the frequency of issue reporting about false positive ODR checks (I received private issue reports too), I'd like to backport this to 18.x too.
2024-01-29 11:42:08 +08:00
[clang] Implement `__is_layout_compatible` (#81506) This patch implements `__is_layout_compatible` intrinsic, which supports `std::is_layout_compatible` type trait introduced in C++20 ([P0466R5](https://wg21.link/p0466r5) "Layout-compatibility and Pointer-interconvertibility Traits"). Name matches GCC and MSVC intrinsic. Basically, this patch exposes our existing machinery for checking for layout compatibility and figuring out common initial sequences. Said machinery is a bit outdated, as it doesn't implement [CWG1719](https://cplusplus.github.io/CWG/issues/1719.html) "Layout compatibility and cv-qualification revisited" and [CWG2759](https://cplusplus.github.io/CWG/issues/2759.html) "`[[no_unique_address]` and common initial sequence". Those defect reports are considered out of scope of of this PR, but will be implemented in subsequent PRs. Partially addresses #48204
2024-02-20 16:54:51 +04:00
- Implemented the `__is_layout_compatible` intrinsic to support
`P0466R5: Layout-compatibility and Pointer-interconvertibility Traits <https://wg21.link/P0466R5>`_.
[C++20] [Modules] Handle transitive import in the module properly Close https://github.com/llvm/llvm-project/issues/84002 Per [module.import]p7: > Additionally, when a module-import-declaration in a module unit of > some module M imports another module unit U of M, it also imports all > translation units imported by non-exported module-import-declarations > in the module unit purview of U. However, we only tried to implement it during the implicit import of primary module interface for module implementation unit. Also we didn't implement the last sentence from [module.import]p7 completely: > These rules can in turn lead to the importation of yet more > translation units. This patch tries to care the both issues.
2024-03-06 15:34:37 +08:00
- Clang now implements [module.import]p7 fully. Clang now will import module
units transitively for the module units coming from the same module of the
current module units.
Fixes `#84002 <https://github.com/llvm/llvm-project/issues/84002>`_.
[clang] Implement CTAD for type alias template. (#77890) Fixes #54051 This patch implements the C++20 feature -- CTAD for alias templates (P1814R0, specified in https://eel.is/c++draft/over.match.class.deduct#3). It is an initial patch: - it cover major pieces, thus it works for most cases; - the big missing piece is to implement the associated constraints (over.match.class.deduct#3.3) for the synthesized deduction guides, see the FIXME in code and tests; - Some enhancements on the TreeTransform&TemplateInstantiator to allow performing instantiation on `BuildingDeductionGuides` mode;
2024-03-08 14:24:03 +01:00
- Initial support for class template argument deduction (CTAD) for type alias
templates (`P1814R0 <https://wg21.link/p1814r0>`_).
(#GH54051).
[clang] Use -std=c++23 instead of -std=c++2b During the ISO C++ Committee meeting plenary session the C++23 Standard has been voted as technical complete. This updates the reference to c++2b to c++23 and updates the __cplusplus macro. Drive-by fixes c++1z -> c++17 and c++2a -> c++20 when seen. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D149553
2023-04-30 15:27:00 +02:00
C++23 Feature Support
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
^^^^^^^^^^^^^^^^^^^^^
[clang] Add separate C++23 extension flag for attrs on lambda (#74553)
2023-12-07 14:52:10 +01:00
[Clang] Implement P2718R0 "Lifetime extension in range-based for loops" (#76361) Implement P2718R0 "Lifetime extension in range-based for loops" (https://wg21.link/P2718R0) Differential Revision: https://reviews.llvm.org/D153701 --------- Signed-off-by: yronglin <yronglin777@gmail.com>
2024-01-30 06:48:14 +08:00
- Implemented `P2718R0: Lifetime extension in range-based for loops <https://wg21.link/P2718R0>`_. Also
materialize temporary object which is a prvalue in discarded-value expression.
[Clang][C++23] Implement P1774R8: Portable assumptions (#81014) This implements the C++23 `[[assume]]` attribute. Assumption information is lowered to a call to `@llvm.assume`, unless the expression has side-effects, in which case it is discarded and a warning is issued to tell the user that the assumption doesn’t do anything. A failed assumption at compile time is an error (unless we are in `MSVCCompat` mode, in which case we don’t check assumptions at compile time). Due to performance regressions in LLVM, assumptions can be disabled with the `-fno-assumptions` flag. With it, assumptions will still be parsed and checked, but no calls to `@llvm.assume` will be emitted and assumptions will not be checked at compile time.
2024-03-09 12:07:16 +01:00
- Implemented `P1774R8: Portable assumptions <https://wg21.link/P1774R8>`_.
[Clang] Implement P2718R0 "Lifetime extension in range-based for loops" (#76361) Implement P2718R0 "Lifetime extension in range-based for loops" (https://wg21.link/P2718R0) Differential Revision: https://reviews.llvm.org/D153701 --------- Signed-off-by: yronglin <yronglin777@gmail.com>
2024-01-30 06:48:14 +08:00
Reapply "[Clang][C++23] Implement P2448R2 ..." (#85136) (#85145) This reverts commit 003e292f9895a9cf4e30688269efa668d1fcbb09 because there were dependent changes in the codebase that now fail.
2024-03-13 16:15:01 -07:00
- Implemented `P2448R2: Relaxing some constexpr restrictions <https://wg21.link/P2448R2>`_.
Add C++26 compile flags. Now that we've updated to C++23, we need to add C++26/C++2c command line flags, as discussed in https://discourse.llvm.org/t/rfc-lets-just-call-it-c-26-and-forget-about-the-c-2c-business-at-least-internally/70383 Differential Revision: https://reviews.llvm.org/D150450
2023-05-12 07:30:21 -07:00
C++2c Feature Support
^^^^^^^^^^^^^^^^^^^^^
[Clang][C++26] Implement Pack Indexing (P2662R3). (#72644) Implements https://isocpp.org/files/papers/P2662R3.pdf The feature is exposed as an extension in older language modes. Mangling is not yet supported and that is something we will have to do before release.
2024-01-27 10:23:38 +01:00
- Implemented `P2662R3 Pack Indexing <https://wg21.link/P2662R3>`_.
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Resolutions to C++ Defect Reports
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[Sema] Substitute parameter packs when deduced from function arguments (#79371) This pull request would solve https://github.com/llvm/llvm-project/issues/78449 . There is also a discussion about this on stackoverflow: https://stackoverflow.com/questions/77832658/stdtype-identity-to-support-several-variadic-argument-lists . The following program is well formed: ```cpp #include <type_traits> template <typename... T> struct args_tag { using type = std::common_type_t<T...>; }; template <typename... T> void bar(args_tag<T...>, std::type_identity_t<T>..., int, std::type_identity_t<T>...) {} // example int main() { bar(args_tag<int, int>{}, 4, 8, 15, 16, 23); } ``` but Clang rejects it, while GCC and MSVC doesn't. The reason for this is that, in `Sema::DeduceTemplateArguments` we are not prepared for this case. # Substitution/deduction of parameter packs The logic that handles substitution when we have explicit template arguments (`SubstituteExplicitTemplateArguments`) does not work here, since the types of the pack are not pushed to `ParamTypes` before the loop starts that does the deduction. The other "candidate" that may could have handle this case would be the loop that does the deduction for trailing packs, but we are not dealing with trailing packs here. # Solution proposed in this PR The solution proposed in this PR works similar to the trailing pack deduction. The main difference here is the end of the deduction cycle. When a non-trailing template pack argument is found, whose type is not explicitly specified and the next type is not a pack type, the length of the previously deduced pack is retrieved (let that length be `s`). After that the next `s` arguments are processed in the same way as in the case of non trailing packs. # Another possible solution There is another possible approach that would be less efficient. In the loop when we get to an element of `ParamTypes` that is a pack and could be substituted because the type is deduced from a previous argument, then `s` number of arg types would be inserted before the current element of `ParamTypes` type. Then we would "cancel" the processing of the current element, first process the previously inserted elements and the after that re-process the current element. Basically we would do what `SubstituteExplicitTemplateArguments` does but during deduction. # Adjusted test cases In `clang/test/CXX/temp/temp.fct.spec/temp.deduct/temp.deduct.call/p1-0x.cpp` there is a test case named `test_pack_not_at_end` that should work, but still does not. This test case is relevant because the note for the error message has changed. This is what the test case looks like currently: ```cpp template<typename ...Types> void pack_not_at_end(tuple<Types...>, Types... values, int); // expected-note {{<int *, double *> vs. <int, int>}} void test_pack_not_at_end(tuple<int*, double*> t2) { pack_not_at_end(t2, 0, 0, 0); // expected-error {{no match}} // FIXME: Should the "original argument type must match deduced parameter // type" rule apply here? pack_not_at_end<int*, double*>(t2, 0, 0, 0); // ok } ``` The previous note said (before my changes): ``` deduced conflicting types for parameter 'Types' (<int *, double *> vs. <>) ```` The current note says (after my changesand also clang 14 would say this if the pack was not trailing): ``` deduced conflicting types for parameter 'Types' (<int *, double *> vs. <int, int>) ``` GCC says: ``` error: no matching function for call to ‘pack_not_at_end(std::tuple<int*, double*>&, int, int, int)’ 70 | pack_not_at_end(t2, 0, 0, 9); // expected-error {{no match}} ```` --------- Co-authored-by: cor3ntin <corentinjabot@gmail.com> Co-authored-by: Erich Keane <ekeane@nvidia.com>
2024-01-27 10:43:38 +01:00
- Substitute template parameter pack, when it is not explicitly specified
in the template parameters, but is deduced from a previous argument.
(`#78449: <https://github.com/llvm/llvm-project/issues/78449>`_).
[Clang] Implement CWG2598: Union of non-literal types (#78195) A union is considered a literal type unless it has no non-literal member. This resolves CWG2096 (which makes unions with literal members literal) and CWG2598 (empty unions are literal types). Fixes #77924
2024-01-17 06:16:12 +01:00
[clang] Implement CWG1719 "Layout compatibility and cv-qualification revisited" (#82358) This patch updates our internal notion of `layout-compatible` to ignore cv-qualification, which in turn fixes `__is_layout_compatible` intrinsic.
2024-02-21 19:02:20 +04:00
- Type qualifications are now ignored when evaluating layout compatibility
of two types.
(`CWG1719: Layout compatibility and cv-qualification revisited <https://cplusplus.github.io/CWG/issues/1719.html>`_).
[clang] Respect field alignment in layout compatibility of structs (#84313) This patch implements [CWG2586](https://cplusplus.github.io/CWG/issues/2583.html) "Common initial sequence should consider over-alignment". Note that alignment of union members doesn't have to match, as layout compatibility of unions is not defined in terms of common initial sequence (http://eel.is/c++draft/class.mem.general#25).
2024-03-08 11:31:00 +04:00
- Alignment of members is now respected when evaluating layout compatibility
of structs.
(`CWG2583: Common initial sequence should consider over-alignment <https://cplusplus.github.io/CWG/issues/2583.html>`_).
[clang] Implement CWG2759 "`[[no_unique_address]` and common initial sequence" (#82607) This patch implements said defect report resolution by adding additional check to common initial sequence evaluation. Consequently, this fixes CWG2759.
2024-02-22 22:30:31 +04:00
- ``[[no_unique_address]]`` is now respected when evaluating layout
compatibility of two types.
(`CWG2759: [[no_unique_address] and common initial sequence <https://cplusplus.github.io/CWG/issues/2759.html>`_).
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
C Language Changes
------------------
[C23] Update user-facing docs for C23 This changes some public references of C2x to be C23, corrects standard citations to use the final paragraph numbers, and adds some information about differences between C17 and C23 modes.
2023-08-10 14:18:36 -04:00
C23 Feature Support
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
^^^^^^^^^^^^^^^^^^^
[C23] Do not diagnose binary literals as an extension (#81658) We previously would diagnose them as a GNU extension in C mode, but they are now a feature of C23. The -Wgnu-binary-literal warning group no longer controls any diagnostics as this is no longer a GNU extension. The warning group is retained as a noop to help avoid "unknown warning" diagnostics. This also adds the companion compatibility warning which existed for C++ but not for C. Fixes https://github.com/llvm/llvm-project/issues/72017
2024-02-14 09:08:28 -05:00
- No longer diagnose use of binary literals as an extension in C23 mode. Fixes
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
#GH72017.
[C23] Complete support for WG14 N2508 (#71398) In Clang 16, we implemented the ability to add a label at the end of a compound statement. These changes complete the implementation by allowing a label to be followed by a declaration in C. Note, this seems to have fixed an issue with some OpenMP stand-alone directives not being properly diagnosed as per: https://www.openmp.org/spec-html/5.1/openmpsu19.html#x34-330002.1.3 (The same requirement exists in OpenMP 5.2 as well.)
2023-11-20 10:52:11 -05:00
[C23] Fix handling of alignas (#81637) In C++, alignas is an attribute specifier, while in C23, it's an alias of _Alignas, which is a type specifier/qualifier. This means that they parse differently in some circumstances. Fixes https://github.com/llvm/llvm-project/issues/81472
2024-02-15 07:58:01 -05:00
- Corrected parsing behavior for the ``alignas`` specifier/qualifier in C23. We
previously handled it as an attribute as in C++, but there are parsing
differences. The behavioral differences are:
.. code-block:: c
struct alignas(8) /* was accepted, now rejected */ S {
char alignas(8) /* was rejected, now accepted */ C;
};
int i alignas(8) /* was accepted, now rejected */ ;
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
Fixes (#GH81472).
[C23] Fix handling of alignas (#81637) In C++, alignas is an attribute specifier, while in C23, it's an alias of _Alignas, which is a type specifier/qualifier. This means that they parse differently in some circumstances. Fixes https://github.com/llvm/llvm-project/issues/81472
2024-02-15 07:58:01 -05:00
[C23] Add __TYPE_FMTB__ and __TYPE_FMTb__ predefined macros (#82361) This adds predefined formatting macros in C23 mode for printing unsigned integers in binary format (e.g, UINT_FAST64_FMTB). These are used to implement the PRIb (et al) macros in inttypes.h Fixes https://github.com/llvm/llvm-project/issues/81896 (Was previously reviewed in [82037](https://github.com/llvm/llvm-project/pull/82037), this is fixing some failures found post-commit.)
2024-02-20 09:32:23 -05:00
- Clang now generates predefined macros of the form ``__TYPE_FMTB__`` and
``__TYPE_FMTb__`` (e.g., ``__UINT_FAST64_FMTB__``) in C23 mode for use with
macros typically exposed from ``<inttypes.h>``, such as ``PRIb8``.
(`#81896: <https://github.com/llvm/llvm-project/issues/81896>`_).
[C23] Implement N3018: The constexpr specifier for object definitions (#73099) The implementation mostly reuses C++ code paths where possible, including narrowing check in order to provide diagnostic messages in case initializer for constexpr variable is not exactly representable in target type. The following won't work due to lack of support for other features: - Diagnosing of underspecified declarations involving constexpr - Constexpr attached to compound literals Also due to lack of support for char8_t some of examples with utf-8 strings don't work properly. Fixes https://github.com/llvm/llvm-project/issues/64742
2024-03-06 11:46:35 +03:00
- Clang now supports `N3018 The constexpr specifier for object definitions`
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3018.htm>`_.
Fix the Sphinx build bot This addresses an accidental break from 41667a8b9b624e282e7c08fadf7091223728d1c1
2022-08-26 10:04:06 -04:00
Non-comprehensive list of changes in this release
-------------------------------------------------
Diagnosing the Future Keywords The patch diagnoses an identifier as a future keyword if it exists in a future language mode, such as: int restrict; in C modes earlier than C99. We now give a warning to the user that such an identifier is a future keyword. Handles keywords from C as well as C++. Differential Revision: https://reviews.llvm.org/D131683
2022-08-26 09:17:14 -04:00
[LLVM] Add `__builtin_readsteadycounter` intrinsic and builtin for realtime clocks (#81331) Summary: This patch adds a new intrinsic and builtin function mirroring the existing `__builtin_readcyclecounter`. The difference is that this implementation targets a separate counter that some targets have which returns a fixed frequency clock that can be used to determine elapsed time, this is different compared to the cycle counter which often has variable frequency. This patch only adds support for the NVPTX and AMDGPU targets. This is done as a new and separate builtin rather than an argument to `readcyclecounter` to avoid needing to change existing code and to make the separation more explicit.
2024-02-13 10:06:25 -06:00
- Added ``__builtin_readsteadycounter`` for reading fixed frequency hardware
counters.
[clang] Allow builtin addc/subc to be constant evaluated (#81656) [clang] Allow builtin addc/subc to be constant evaluated
2024-02-15 09:41:19 -06:00
- ``__builtin_addc``, ``__builtin_subc``, and the other sizes of those
builtins are now constexpr and may be used in constant expressions.
[Clang] Implement constexpr support for `__builtin_popcountg` (#84318)
2024-03-08 00:01:37 +00:00
- Added ``__builtin_popcountg`` as a type-generic alternative to
``__builtin_popcount{,l,ll}`` with support for any unsigned integer type. Like
the previous builtins, this new builtin is constexpr and may be used in
constant expressions.
[clang] Accept lambdas in C++03 as an extensions (#73376) Implements https://discourse.llvm.org/t/rfc-allow-c-11-lambdas-in-c-03-as-an-extension/75262
2024-03-21 12:57:24 +01:00
- Lambda expressions are now accepted in C++03 mode as an extension.
[clang] Implement constexpr support for __builtin_{clzg,ctzg} (#86577) Fixes #86549.
2024-03-26 20:22:47 +00:00
- Added ``__builtin_clzg`` and ``__builtin_ctzg`` as type-generic alternatives
to ``__builtin_clz{,s,l,ll}`` and ``__builtin_ctz{,s,l,ll}`` respectively,
with support for any unsigned integer type. Like the previous builtins, these
new builtins are constexpr and may be used in constant expressions.
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
New Compiler Flags
------------------
Add -fkeep-system-includes modifier for -E This option will cause -E to preserve the #include directives for system headers, rather than expanding them into the output. This can greatly reduce the volume of preprocessed source text in a test case, making test case reduction simpler. Note that -fkeep-system-includes is not always appropriate. For example, if the problem you want to reproduce is induced by a system header file, it's better to expand those headers fully. If your source defines symbols that influence the content of a system header (e.g., _POSIX_SOURCE) then -E will eliminate the definition, potentially changing the meaning of the preprocessed source. If you use -isystem to point to non-system headers, for example to suppress warnings in third-party software, those will not be expanded and might make the preprocessed source less useful as a test case.
2023-09-28 07:18:11 -07:00
[clang] Add -Wmissing-designated-field-initializers (#81364) #56628 changed the behavior of `-Wmissing-field-initializers`, which introduces many new warnings in C++ code that uses partial designated initializers. If such code is being built with `-Wextra -Werror`, this change will break the build. This PR adds a new flag that allows to disable these new warnings and keep the old ones, as was suggested by @AaronBallman in the original issue: https://github.com/llvm/llvm-project/issues/56628#issuecomment-1761510850 Fixes #68933
2024-03-05 19:27:58 +03:00
- ``-Wmissing-designated-field-initializers``, grouped under ``-Wmissing-field-initializers``.
This diagnostic can be disabled to make ``-Wmissing-field-initializers`` behave
like it did before Clang 18.x. Fixes (`#56628 <https://github.com/llvm/llvm-project/issues/68933>`_)
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
Deprecated Compiler Flags
-------------------------
Modified Compiler Flags
-----------------------
Add new flag -Wreturn-mismatch (#82872) This pull request fixes #72116 where a new flag is introduced for compatibility with GCC 14, the functionality of -Wreturn-type is modified to split some of its behaviors into -Wreturn-mismatch Fixes #72116
2024-03-11 22:55:32 +05:30
- Added a new diagnostic flag ``-Wreturn-mismatch`` which is grouped under
``-Wreturn-type``, and moved some of the diagnostics previously controlled by
``-Wreturn-type`` under this new flag. Fixes #GH72116.
[docs] Add release notes for news in 16.x done by me, or otherwise relating to MinGW targets Differential Revision: https://reviews.llvm.org/D142346
2023-01-23 13:25:55 +02:00
Split -Wcast-function-type into a separate group (#86131) We want to add -Wcast-function-type to -Wextra (as done in 1de7e6c8cba27296f3fc16d107822ea0ee856759), but we do not want to add -Wcast-function-type-strict in at the same time (https://lab.llvm.org/buildbot/#/builders/57/builds/33601/steps/5/logs/stdio). This moves the existing warning to a new group (-Wcast-function-type-mismatch), puts the new group under the existing -Wcast-function-type warning group, and adds -Wcast-function-type-mismatch to -Wextra.
2024-03-21 14:18:43 -04:00
- Added ``-Wcast-function-type-mismatch`` under the ``-Wcast-function-type``
warning group. Moved the diagnostic previously controlled by
``-Wcast-function-type`` to the new warning group and added
``-Wcast-function-type-mismatch`` to ``-Wextra``. #GH76872
.. code-block:: c
int x(long);
typedef int (f2)(void*);
typedef int (f3)();
void func(void) {
// Diagnoses under -Wcast-function-type, -Wcast-function-type-mismatch,
// -Wcast-function-type-strict, -Wextra
f2 *b = (f2 *)x;
// Diagnoses under -Wcast-function-type, -Wcast-function-type-strict
f3 *c = (f3 *)x;
}
[clang] move -Wcast-function-type under -Wextra (#77178) The -Wcast-fuction-type-strict has been moved under dignstic group -Wextra. Edited the test cases for -Wcast-fuction-type-strict and -Wcast-fuction-type in Sema an SemaCXX. Added a new test case which include a functionality that was already in the -Wextra group, i.e -Wignored-qualifiers with -Wcast-fuction-type-strict. Fixes: #76872
2024-03-20 13:34:46 +01:00
clang-cl: Remove /Zd flag cl.exe doesn't understand Zd (in either MSVC 2017 or 2019), so neiter should we. It used to do the same as `-gline-tables-only` which is exposed as clang-cl flag as well, so if you want this behavior, use `gline-tables-only`. That makes it clear that it's a clang-cl-only flag that won't work with cl.exe. Motivated by the discussion in D92958. Differential Revision: https://reviews.llvm.org/D93458
2020-12-17 09:23:02 -05:00
Removed Compiler Flags
-------------------------
[Driver] Remove dead -freroll-loops flag (#82254) Remove the `-freroll-loops` flag, which has not had any effect since the migration to the new pass manager. The underlying pass has been removed entirely in #80972 due to lack of maintenance and known bugs. Fixes https://github.com/llvm/llvm-project/issues/59065.
2024-02-20 13:50:41 +01:00
- The ``-freroll-loops`` flag has been removed. It had no effect since Clang 13.
[Driver] Don't alias -mstrict-align to -mno-unaligned-access GCC ports only supports one of the options, with -mstrict-align preferred by newer ports. They reject adding -m[no-]unaligned-access to newer ports that use -m[no-]strict-align. (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111555). We should not support aliases, either. Since the behavior has been long-time for ARM (a146a48349c965932dcf304ffb8155b25307f245), support both forms for ARM for now but remove -m[no-]unaligned-access for RISC-V/LoongArch (see also https://github.com/riscv-non-isa/riscv-c-api-doc/pull/62). While here, add TargetSpecific to ensure errors on unsupported targets (https://reviews.llvm.org/D151590) and remove unneeded CC1 options. Pull Request: https://github.com/llvm/llvm-project/pull/85350
2024-03-15 10:50:21 -07:00
- ``-m[no-]unaligned-access`` is removed for RISC-V and LoongArch.
``-m[no-]strict-align``, also supported by GCC, should be used instead.
(`#85350 <https://github.com/llvm/llvm-project/pull/85350>`_.)
[Driver] Remove dead -freroll-loops flag (#82254) Remove the `-freroll-loops` flag, which has not had any effect since the migration to the new pass manager. The underlying pass has been removed entirely in #80972 due to lack of maintenance and known bugs. Fixes https://github.com/llvm/llvm-project/issues/59065.
2024-02-20 13:50:41 +01:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
Attribute Changes in Clang
--------------------------
[AMDGPU] Adding the amdgpu_num_work_groups function attribute (#79035) A new function attribute named amdgpu_num_work_groups is added. This attribute, which consists of three integers, allows programmers to let the compiler know the number of workgroups to be launched in each of the three dimensions and do optimizations based on that information. --------- Co-authored-by: Jun Wang <jun.wang7@amd.com>
2024-03-12 10:30:39 -07:00
- Introduced a new function attribute ``__attribute__((amdgpu_max_num_work_groups(x, y, z)))`` or
``[[clang::amdgpu_max_num_work_groups(x, y, z)]]`` for the AMDGPU target. This attribute can be
attached to HIP or OpenCL kernel function definitions to provide an optimization hint. The parameters
``x``, ``y``, and ``z`` specify the maximum number of workgroups for the respective dimensions,
and each must be a positive integer when provided. The parameter ``x`` is required, while ``y`` and
``z`` are optional with default value of 1.
[coroutines] Introduce [[clang::coro_lifetimebound]] (#72851) Adds attribute `[[clang::coro_lifetimebound]]`. All arguments to a function are considered to be **lifetime bound** if the function returns a type annotated with ``[[clang::coro_lifetimebound]]`` and ``[[clang::coro_return_type]]``.
2023-11-22 12:51:24 +01:00
[clang] Add `__has_extension(swiftcc)` support (#85347)
2024-03-20 21:18:57 +09:00
- The ``swiftasynccc`` attribute is now considered to be a Clang extension
rather than a language standard feature. Please use
``__has_extension(swiftasynccc)`` to check the availability of this attribute
for the target platform instead of ``__has_feature(swiftasynccc)``. Also,
added a new extension query ``__has_extension(swiftcc)`` corresponding to the
``__attribute__((swiftcc))`` attribute.
Reapply "[clang][nullability] allow _Nonnull etc on nullable class types (#82705)" (#87325) This reverts commit 28760b63bbf9e267713957105a8d17091fb0d20e. The last commit was missing the new testcase, now fixed.
2024-04-02 13:48:45 +02:00
- The ``_Nullable`` and ``_Nonnull`` family of type attributes can now apply
to certain C++ class types, such as smart pointers:
``void useObject(std::unique_ptr<Object> _Nonnull obj);``.
This works for standard library types including ``unique_ptr``, ``shared_ptr``,
and ``function``. See
`the attribute reference documentation <https://llvm.org/docs/AttributeReference.html#nullability-attributes>`_
for the full list.
- The ``_Nullable`` attribute can be applied to C++ class declarations:
``template <class T> class _Nullable MySmartPointer {};``.
This allows the ``_Nullable`` and ``_Nonnull`` family of type attributes to
apply to this class.
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Improvements to Clang's diagnostics
-----------------------------------
[clang][Diagnostics] Highlight code snippets (#66514) Add some primitive syntax highlighting to our code snippet output. This adds "checkpoints" to the Preprocessor, which we can use to start lexing from. When printing a code snippet, we lex from the nearest checkpoint and highlight the tokens based on their token type.
2024-01-27 17:52:20 +01:00
- Clang now applies syntax highlighting to the code snippets it
prints.
[Sema] -Wzero-as-null-pointer-constant: don't warn for __null (#69126) The implementation of -Wzero-as-null-pointer-constant was done before the following fix has been committed to GCC: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=752e7593b0f19af233a0b7e72daab8413662b605;hp=298434c916c14e8adca2cab8a746aee29038c5b3 As a result, clang and gcc diverge on the use of `__null` and, consequently, on the use of `NULL` on systems like Linux/macOS where `NULL` is defined as `__null`. This is a problem for compatibility between gcc and clang, particularly for code bases that support C++98 or for single-source libraries that are implemented in C, but compiled as C++ via inclusion into a C++ translation unit. Code like this can not be changed to use `nullptr`, as it needs to maintain compatibility with C before C23 or C++ before C++11, but warns on the use of `NULL` in clang. The warning `Wzero-as-null-pointer-constant` is still useful with this change, as it allows to change `0` to `NULL`, which fixes gcc warnings and helps the reader distinguish between pointers and non-pointers. Users who require a full C++11 modernization pass can still use clang-tidy for that purpose.
2023-10-25 08:58:28 -07:00
[Clang][Parse] Diagnose member template declarations with multiple declarators (#78243) According to [temp.pre] p5: > In a template-declaration, explicit specialization, or explicit instantiation the init-declarator-list in the declaration shall contain at most one declarator. A member-declaration that is a template-declaration or explicit-specialization contains a declaration, even though it declares a member. This means it _will_ contain an init-declarator-list (not a member-declarator-list), so [temp.pre] p5 applies. This diagnoses declarations such as: ``` struct A { template<typename T> static const int x = 0, f(); // error: a template declaration can only declare a single entity template<typename T> static const int g(), y = 0; // error: a template declaration can only declare a single entity }; ``` The diagnostic messages are the same as those of the equivalent namespace scope declarations. Note: since we currently do not diagnose declarations with multiple abbreviated function template declarators at namespace scope e.g., `void f(auto), g(auto);`, so this patch does not add diagnostics for the equivalent member declarations. This patch also refactors `ParseSingleDeclarationAfterTemplate` (now named `ParseDeclarationAfterTemplate`) to call `ParseDeclGroup` and return the resultant `DeclGroup`.
2024-02-01 11:19:04 -05:00
- Clang now diagnoses member template declarations with multiple declarators.
[clang][Sema] Subclass `-Wshorten-64-to-32` under `-Wimplicit-int-conversion` (#80814) Although "implicit int conversions" is supposed to be a superset containing the more specific "64-to-32" case, previously they were a disjoint set, only enabled in common in the much larger `-Wconversion`.
2024-02-08 13:37:55 +01:00
- Clang now diagnoses use of the ``template`` keyword after declarative nested
name specifiers.
- The ``-Wshorten-64-to-32`` diagnostic is now grouped under ``-Wimplicit-int-conversion`` instead
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
of ``-Wconversion``. Fixes #GH69444.
[Clang][Parse] Diagnose member template declarations with multiple declarators (#78243) According to [temp.pre] p5: > In a template-declaration, explicit specialization, or explicit instantiation the init-declarator-list in the declaration shall contain at most one declarator. A member-declaration that is a template-declaration or explicit-specialization contains a declaration, even though it declares a member. This means it _will_ contain an init-declarator-list (not a member-declarator-list), so [temp.pre] p5 applies. This diagnoses declarations such as: ``` struct A { template<typename T> static const int x = 0, f(); // error: a template declaration can only declare a single entity template<typename T> static const int g(), y = 0; // error: a template declaration can only declare a single entity }; ``` The diagnostic messages are the same as those of the equivalent namespace scope declarations. Note: since we currently do not diagnose declarations with multiple abbreviated function template declarators at namespace scope e.g., `void f(auto), g(auto);`, so this patch does not add diagnostics for the equivalent member declarations. This patch also refactors `ParseSingleDeclarationAfterTemplate` (now named `ParseDeclarationAfterTemplate`) to call `ParseDeclGroup` and return the resultant `DeclGroup`.
2024-02-01 11:19:04 -05:00
[clang] Use separator for large numeric values in overflow diagnostic (#80939) Add functionality to APInt::toString() that allows it to insert separators between groups of digits, using the C++ literal separator ' between groups. Fixes issue #58228 Reviewers: @AaronBallman, @cjdb, @tbaederr
2024-03-05 04:38:42 -08:00
- Clang now uses thousand separators when printing large numbers in integer overflow diagnostics.
Fixes #GH80939.
[Clang][Sema] Diagnose friend declarations with enum elaborated-type-specifier in all language modes (#80171) According to [dcl.type.elab] p4: > If an _elaborated-type-specifier_ appears with the `friend` specifier as an entire _member-declaration_, the _member-declaration_ shall have one of the following forms: > `friend` _class-key_ _nested-name-specifier_(opt) _identifier_ `;` > `friend` _class-key_ _simple-template-id_ `;` > `friend` _class-key_ _nested-name-specifier_ `template`(opt) _simple-template-id_ `;` Notably absent from this list is the `enum` form of an _elaborated-type-specifier_ "`enum` _nested-name-specifier_(opt) _identifier_", which appears to be intentional per the resolution of CWG2363. Most major implementations accept these declarations, so the diagnostic is a pedantic warning across all C++ versions. In addition to the trivial cases previously diagnosed in C++98, we now diagnose cases where the _elaborated-type-specifier_ has a dependent _nested-name-specifier_: ``` template<typename T> struct A { enum class E; }; struct B { template<typename T> friend enum A<T>::E; // pedantic warning: elaborated enumeration type cannot be a friend }; template<typename T> struct C { friend enum T::E; // pedantic warning: elaborated enumeration type cannot be a friend }; ```
2024-02-13 14:25:56 -05:00
- Clang now diagnoses friend declarations with an ``enum`` elaborated-type-specifier in language modes after C++98.
[C11] Diagnose C11 keywords as being incompatible w/earlier standards (#82015) Our usual pattern when issuing an extension warning is to also issue a default-off diagnostic about the keywords not being compatible with standards before a certain point. This adds those diagnostics for C11 keywords.
2024-02-16 15:08:04 -05:00
- Added diagnostics for C11 keywords being incompatible with language standards
before C11, under a new warning group: ``-Wpre-c11-compat``.
[C23] No longer assert on huge enumerator values (#81760) C23 added the wb and uwb suffixes to generate a bit-precise integer value. These values can be larger than what is representable in intmax_t or uintmax_t. We were asserting that an enumerator constant could not have a value larger than unsigned long long but that's now a possibility. This patch turns the assertion into a "value too large" diagnostic. Note, we do not yet implement WG14 N3029 and so the behavior of this patch will cause the enumerator to be cast to unsigned long long, but this behavior may change in the future. GCC selects __uint128_t as the underlying type for such an enumeration and we may want to match that behavior in the future. This patch has several FIXME comments related to this and the release notes call out the possibility of a change in behavior in the future. Fixes https://github.com/llvm/llvm-project/issues/69352
2024-02-20 11:58:03 -05:00
- Now diagnoses an enumeration constant whose value is larger than can be
represented by ``unsigned long long``, which can happen with a large constant
using the ``wb`` or ``uwb`` suffix. The maximal underlying type is currently
``unsigned long long``, but this behavior may change in the future when Clang
implements
`WG14 N3029 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3029.htm>`_.
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
(#GH69352).
[C23] No longer assert on huge enumerator values (#81760) C23 added the wb and uwb suffixes to generate a bit-precise integer value. These values can be larger than what is representable in intmax_t or uintmax_t. We were asserting that an enumerator constant could not have a value larger than unsigned long long but that's now a possibility. This patch turns the assertion into a "value too large" diagnostic. Note, we do not yet implement WG14 N3029 and so the behavior of this patch will cause the enumerator to be cast to unsigned long long, but this behavior may change in the future. GCC selects __uint128_t as the underlying type for such an enumeration and we may want to match that behavior in the future. This patch has several FIXME comments related to this and the release notes call out the possibility of a change in behavior in the future. Fixes https://github.com/llvm/llvm-project/issues/69352
2024-02-20 11:58:03 -05:00
[Clang][Sema] Convert warning for extraneous template parameter lists to an extension warning (#82277) We currently accept the following explicit specialization with a warning for the extraneous template parameter list: ``` template<typename T> void f(); template<> template<> void f<int>(); // warning: extraneous template parameter list in template specialization ``` This should really be an extension warning so we reject with `-pedantic-errors`. This patch converts the warning to an extension warning.
2024-02-20 13:12:32 -05:00
- Clang now diagnoses extraneous template parameter lists as a language extension.
[Clang][Sema] Diagnose declarative nested-name-specifiers naming alias templates (#80842) According to [expr.prim.id.qual] p3: > The _nested-name-specifier_ `​::` nominates the global namespace. A _nested-name-specifier_ with a _computed-type-specifier_ nominates the type denoted by the _computed-type-specifier_, which shall be a class or enumeration type. **If a _nested-name-specifier_ `N` is declarative and has a _simple-template-id_ with a template argument list `A` that involves a template parameter, let `T` be the template nominated by `N` without `A`. `T` shall be a class template.** Meaning, the out-of-line definition of `A::f` in the following example is ill-formed: ``` template<typename T> struct A { void f(); }; template<typename T> using B = A<T>; template<typename T> void B<T>::f() { } // error: a declarative nested name specifier cannot name an alias template ``` This patch diagnoses such cases as an extension (in group `alias-template-in-declaration-name`).
2024-02-20 13:25:12 -05:00
- Clang now diagnoses declarative nested name specifiers that name alias templates.
[Clang][Sema]: Diagnose lambda to bool implicit casts (#83152) Adds diagnostics for lambda expressions being cast to boolean values, which results in the expression always evaluating to true. Earlier, Clang allowed compilation of such erroneous programs, but now emits a warning through `-Wpointer-bool-conversion`. Fixes #82512
2024-02-29 19:39:39 +05:30
- Clang now diagnoses lambda function expressions being implicitly cast to boolean values, under ``-Wpointer-bool-conversion``.
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
Fixes #GH82512.
[Clang][Sema]: Diagnose lambda to bool implicit casts (#83152) Adds diagnostics for lambda expressions being cast to boolean values, which results in the expression always evaluating to true. Earlier, Clang allowed compilation of such erroneous programs, but now emits a warning through `-Wpointer-bool-conversion`. Fixes #82512
2024-02-29 19:39:39 +05:30
Diagnose misuse of the cleanup attribute (#80040) This pull request fixes #79443 when the cleanup attribute is intended to be applied to a variable declaration, passing its address to a specified function. The problem arises when standard functions like free, closedir, fclose, etc., are used incorrectly with this attribute, leading to incorrect behavior. Fixes #79443
2024-03-13 21:58:25 +05:30
- Clang now provides improved warnings for the ``cleanup`` attribute to detect misuse scenarios,
such as attempting to call ``free`` on an unallocated object. Fixes
`#79443 <https://github.com/llvm/llvm-project/issues/79443>`_.
fix unnecessary warning when using bitand with boolean operators (#81976) This pull request fixes #77601 where using the `bitand` operator with boolean operands should not trigger the warning, as it would indicate an intentional use of bitwise AND rather than a typo or error. Fixes #77601
2024-03-18 17:49:44 +05:30
- Clang no longer warns when the ``bitand`` operator is used with boolean
operands, distinguishing it from potential typographical errors or unintended
bitwise operations. Fixes #GH77601.
[Clang] Update missing varargs arg extension warnings (#84520) This updates a few warnings that were diagnosing no arguments for a `...` variadic macro parameter as a GNU extension when it actually is a C++20/C23 extension now. This fixes #84495.
2024-03-20 19:19:30 +01:00
- Clang now correctly diagnoses no arguments to a variadic macro parameter as a C23/C++20 extension.
Fixes #GH84495.
[[clang::always_destroy]] attribute silences warn-exit-time-destructor (#86486) This attribute tells the compiler that the variable must have its exit-time destructor run, so it makes sense that it would silence the warning telling users that an exit-time destructor is required. Fixes https://github.com/llvm/llvm-project/issues/68686
2024-03-26 13:38:31 +01:00
- Clang no longer emits a ``-Wexit-time destructors`` warning on static variables explicitly
annotated with the ``clang::always_destroy`` attribute.
Fixes #GH68686, #GH86486
[Clang][Sema] Allow flexible arrays in unions and alone in structs (#84428) GNU and MSVC have extensions where flexible array members (or their equivalent) can be in unions or alone in structs. This is already fully supported in Clang through the 0-sized array ("fake flexible array") extension or when C99 flexible array members have been syntactically obfuscated. Clang needs to explicitly allow these extensions directly for C99 flexible arrays, since they are common code patterns in active use by the Linux kernel (and other projects). Such projects have been using either 0-sized arrays (which is considered deprecated in favor of C99 flexible array members) or via obfuscated syntax, both of which complicate their code bases. For example, these do not error by default: ``` union one { int a; int b[0]; }; union two { int a; struct { struct { } __empty; int b[]; }; }; ``` But this does: ``` union three { int a; int b[]; }; ``` Remove the default error diagnostics for this but continue to provide warnings under Microsoft or GNU extensions checks. This will allow for a seamless transition for code bases away from 0-sized arrays without losing existing code patterns. Add explicit checking for the warnings under various constructions. Additionally fixes a CodeGen bug with flexible array members in unions in C++, which was found when adding a testcase for: ``` union { char x[]; } z = {0}; ``` which only had Sema tests originally. Fixes #84565
2024-03-27 15:56:19 -07:00
- ``-Wmicrosoft``, ``-Wgnu``, or ``-pedantic`` is now required to diagnose C99
flexible array members in a union or alone in a struct. Fixes GH#84565.
[Clang] [Sema] No longer diagnose type definitions in `offsetof` in C23 mode (#84169) This is now allowed in C23; continue to diagnose it in earlier language modes as before, but now as a C23 extension rather than a GNU extension. This fixes #83658.
2024-03-29 17:42:09 +01:00
- Clang now no longer diagnoses type definitions in ``offsetof`` in C23 mode.
Fixes #GH83658.
[Sema] Implement support for -Wformat-signedness (#74440) In gcc there exist a modifier option -Wformat-signedness that turns on additional signedness warnings in the already existing -Wformat warning. This patch implements that support in clang. This is done by adding a dummy warning diag::warn_format_conversion_argument_type_mismatch_signedness that is never emitted and only used as an option to toggle the signedness warning in -Wformat. This will ensure gcc compatibility.
2024-03-31 11:09:52 +02:00
- New ``-Wformat-signedness`` diagnostic that warn if the format string requires an
unsigned argument and the argument is signed and vice versa.
Add two time-trace scope variables. A time trace scope variable of `ParseDeclarationOrFunctionDefinition` with the function's source location is added to record the time spent parsing the function's declaration or definition. Another time trace scope variable of `ParseFunctionDefinition` is also added to record the name of the defined function. A release note is added as well. Reviewed by: Aaron Ballman Pull request: #65268
2023-09-01 15:30:44 +01:00
Improvements to Clang's time-trace
----------------------------------
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Bug Fixes in This Version
-------------------------
[Clang][Sema] Fix missing warning when comparing mismatched enums in … (#81418) …C mode Factored logic from `CheckImplicitConversion` into new methods `Expr::getEnumConstantDecl` and `Expr::getEnumCoercedType` for use in `checkEnumArithmeticConversions`. Fix #29217
2024-02-27 11:58:59 -03:00
- Fixed missing warnings when comparing mismatched enumeration constants
in C (`#29217 <https://github.com/llvm/llvm-project/issues/29217>`).
[Clang][Sema] Allow elaborated-type-specifiers that declare member class template explict specializations (#78720) According to [[dcl.type.elab] p2](http://eel.is/c++draft/dcl.type.elab#2): > If an [elaborated-type-specifier](http://eel.is/c++draft/dcl.type.elab#nt:elaborated-type-specifier) is the sole constituent of a declaration, the declaration is ill-formed unless it is an explicit specialization, an explicit instantiation or it has one of the following forms [...] Consider the following: ```cpp template<typename T> struct A { template<typename U> struct B; }; template<> template<typename U> struct A<int>::B; // #1 ``` The _elaborated-type-specifier_ at `#1` declares an explicit specialization (which is itself a template). We currently (incorrectly) reject this, and this PR fixes that. I moved the point at which _elaborated-type-specifiers_ with _nested-name-specifiers_ are diagnosed from `ParsedFreeStandingDeclSpec` to `ActOnTag` for two reasons: `ActOnTag` isn't called for explicit instantiations and partial/explicit specializations, and because it's where we determine if a member specialization is being declared. With respect to diagnostics, I am currently issuing the diagnostic without marking the declaration as invalid or returning early, which results in more diagnostics that I think is necessary. I would like feedback regarding what the "correct" behavior should be here.
2024-01-30 08:28:13 -05:00
- Clang now accepts elaborated-type-specifiers that explicitly specialize
a member class template for an implicit instantiation of a class template.
[Sema] Handle large shift counts in GetExprRange (#68590) GetExprRange did not expect that very large shift counts when narrowing the range based on logical right shifts. So with inputs such as *a >> 123456789012345678901uwb it would hit assertions about trying to convert a too large APInt into uint64_t. This patch fixes that by using the APInt value when determining if we should reduce the range by the shift count or not.
2023-10-10 10:25:01 +02:00
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
- Fixed missing warnings when doing bool-like conversions in C23 (#GH79435).
[clang] Avoid -Wshadow warning when init-capture named same as class field (#74512) Shadowing warning doesn't make much sense since field is not available in lambda's body without capturing this. Fixes https://github.com/llvm/llvm-project/issues/71976
2024-02-12 12:44:20 +03:00
- Clang's ``-Wshadow`` no longer warns when an init-capture is named the same as
a class field unless the lambda can capture this.
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
Fixes (#GH71976)
[Sema] Fix c23 not checking CheckBoolLikeConversion (#79588) Fixes issue #79435 Checks for implicit conversion into boolean was previously triggered by `CheckBoolLikeConversion` for C. When `bool` as a keyword was introduced in C23, `CheckBoolLikeConversion` would no longer trigger when using `-std=c23`, but since logical operators and conditional statements still operate on scalar values, the checks for implicit conversion into bool were never triggered. This fix changes `CheckBoolLikeConversion` to not return early for C23, even though it has support for bools.
2024-01-30 19:20:15 +01:00
[Clang][Sema] Correctly look up primary template for variable template specializations (#80359) Consider the following: ``` namespace N0 { namespace N1 { template<typename T> int x1 = 0; } using namespace N1; } template<> int N0::x1<int>; ``` According to [dcl.meaning.general] p3.3: > - If the _declarator_ declares an explicit instantiation or a partial or explicit specialization, the _declarator_ does not bind a name. If it declares a class member, the terminal name of the _declarator-id_ is not looked up; otherwise, **only those lookup results that are nominable in `S` are considered when identifying any function template specialization being declared**. In particular, the requirement for lookup results to be nominal in the lookup context of the terminal name of the _declarator-id_ only applies to function template specializations -- not variable template specializations. We currently reject the above declaration, but we do (correctly) accept it if the using-directive is replaced with a `using` declaration naming `N0::N1::x1`. This patch makes it so the above specialization is (correctly) accepted.
2024-02-02 12:53:34 -05:00
- Clang now accepts qualified partial/explicit specializations of variable templates that
are not nominable in the lookup context of the specialization.
[clang] Fix unexpected `-Wconstant-logical-operand` in C23 (#80724) C23 has `bool`, but logical operators still return int. Check that we're not in C to avoid false-positive -Wconstant-logical-operand. Fixes https://github.com/llvm/llvm-project/issues/64356
2024-02-06 15:57:35 +03:00
- Clang now doesn't produce false-positive warning `-Wconstant-logical-operand`
for logical operators in C23.
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
Fixes (#GH64356).
[clang] Fix unexpected `-Wconstant-logical-operand` in C23 (#80724) C23 has `bool`, but logical operators still return int. Check that we're not in C to avoid false-positive -Wconstant-logical-operand. Fixes https://github.com/llvm/llvm-project/issues/64356
2024-02-06 15:57:35 +03:00
[clang] Fix behavior of `__is_trivially_relocatable(volatile int)` (#77092) Consistent with `__is_trivially_copyable(volatile int) == true` and `__is_trivially_relocatable(volatile Trivial) == true`, `__is_trivially_relocatable(volatile int)` should also be `true`. Fixes https://github.com/llvm/llvm-project/issues/77091 [clang] [test] New tests for __is_trivially_relocatable(cv-qualified type)
2024-03-11 06:53:23 +03:30
- ``__is_trivially_relocatable`` no longer returns ``false`` for volatile-qualified types.
Fixes (#GH77091).
[Clang][Sema]: Allow copy constructor side effects (#81127) Copy constructors can have initialization with side effects, and thus clang should not emit a warning when -Wunused-variable is used in this context. Currently however, a warning is emitted. Now, compilation happens without warnings. Fixes #79518
2024-03-01 21:10:46 +05:30
- Clang no longer produces a false-positive `-Wunused-variable` warning
for variables created through copy initialization having side-effects in C++17 and later.
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
Fixes (#GH64356) (#GH79518).
[Clang][Sema]: Allow copy constructor side effects (#81127) Copy constructors can have initialization with side effects, and thus clang should not emit a warning when -Wunused-variable is used in this context. Currently however, a warning is emitted. Now, compilation happens without warnings. Fixes #79518
2024-03-01 21:10:46 +05:30
[clang-cl] Fix value of __FUNCTION__ in MSVC mode. (#84014) Predefined macro FUNCTION in clang is not returning the same string than MS for templated functions. See https://godbolt.org/z/q3EKn5zq4 For the same test case MSVC is returning: function: TestClass::TestClass function: TestStruct::TestStruct function: TestEnum::TestEnum The initial work for this was in the reverted patch (https://github.com/llvm/llvm-project/pull/66120). This patch solves the issues raised in the reverted patch.
2024-03-19 07:55:49 -07:00
- Fix value of predefined macro ``__FUNCTION__`` in MSVC compatibility mode.
Fixes (#GH66114).
[clang] Error on explicit specialization of lambda call operator (#84343) Fixes https://github.com/llvm/llvm-project/issues/83267
2024-03-08 11:52:42 +03:00
- Clang now emits errors for explicit specializations/instatiations of lambda call
operator.
Fixes (#GH83267).
Add bit-precise overloads for builtin operators (#84755) We previously were not adding them to the candidate set and so use of a bit-precise integer as a class member could lead to ambiguous overload sets. Fixes https://github.com/llvm/llvm-project/issues/82998
2024-03-12 07:40:27 -04:00
- Clang now correctly generates overloads for bit-precise integer types for
builtin operators in C++. Fixes #GH82998.
[Clang] [Sema] Fix bug in `_Complex float`+`int` arithmetic (#83063) C23 6.3.1.8 ‘Usual arithmetic conversions’ p1 states (emphasis mine): > Otherwise, if the corresponding real type of either operand is `float`, the other operand is converted, *without change of type domain*, to a type whose corresponding real type is `float`. ‘type domain’ here refers to `_Complex` vs real (i.e. non-`_Complex`); there is another clause that states the same for `double`. Consider the following code: ```c++ _Complex float f; int x; f / x; ``` After talking this over with @AaronBallman, we came to the conclusion that `x` should be converted to `float` and *not* `_Complex float` (that is, we should perform a division of `_Complex float / float`, and *not* `_Complex float / _Complex float`; the same also applies to `-+*`). This was already being done correctly for cases where `x` was already a `float`; it’s just mixed `_Complex float`+`int` operations that currently suffer from this problem. This pr removes the extra `FloatingRealToComplex` conversion that we were erroneously inserting and adds some tests to make sure we’re actually doing `_Complex float / float` and not `_Complex float / _Complex float` (and analogously for `double` and `-+*`). The only exception here is `float / _Complex float`, which calls a library function (`__divsc3`) that takes 4 `float`s, so we end up having to convert the `float` to a `_Complex float` after all (and analogously for `double`); I don’t believe there is a way around this. Lastly, we were also missing tests for `_Complex` arithmetic at compile time, so this adds some tests for that as well.
2024-03-13 17:39:23 +01:00
- When performing mixed arithmetic between ``_Complex`` floating-point types and integers,
Clang now correctly promotes the integer to its corresponding real floating-point
type only rather than to the complex type (e.g. ``_Complex float / int`` is now evaluated
as ``_Complex float / float`` rather than ``_Complex float / _Complex float``), as mandated
by the C standard. This significantly improves codegen of `*` and `/` especially.
Fixes (`#31205 <https://github.com/llvm/llvm-project/issues/31205>`_).
Reapply "[clang] Fix crash when declaring invalid lambda member" (#85427) This re-applies #74110 with the crashing code disabled in C++11. I'll try to fix the new crash in it's own patch.
2024-03-16 12:36:33 +01:00
- Fixes an assertion failure on invalid code when trying to define member
functions in lambdas.
[clang][Sema] Fix a CTAD regression after 42239d2e9 (#86914) The most recent declaration of a template as a friend can introduce a different template parameter depth compared to what we anticipate from a CTAD guide. Fixes https://github.com/llvm/llvm-project/issues/86769
2024-03-29 23:28:54 +08:00
- Fixed a regression in CTAD that a friend declaration that befriends itself may cause
incorrect constraint substitution. (#GH86769).
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Bug Fixes to Compiler Builtins
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[clang][AIX] Don't ignore XCOFF visibility by default D87451 added -mignore-xcoff-visibility for AIX targets and made it the default (which mimicked the behaviour of the XL 16.1 compiler on AIX). However, ignoring hidden visibility has unwanted side effects and some libraries depend on visibility to hide non-ABI facing entities from user headers and reserve the right to change these implementation details based on this (https://libcxx.llvm.org/DesignDocs/VisibilityMacros.html). This forces us to use internal linkage fallbacks for these cases on AIX and creates an unwanted divergence in implementations on the plaform. For these reasons, it's preferable to not add -mignore-xcoff-visibility by default, which is what this patch does. Reviewed By: DiggerLin Differential Revision: https://reviews.llvm.org/D125141
2022-05-02 17:06:04 -04:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Bug Fixes to Attribute Support
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[clang][Sema] check default argument promotions for printf The main focus of this patch is to make ArgType::matchesType check for possible default parameter promotions when the argType is not a pointer. If so, no warning will be given for `int`, `unsigned int` types as corresponding arguments to %hhd and %hd. However, the usage of %hhd corresponding to short is relatively rare, and it is more likely to be a misuse. This patch keeps the original behavior of clang like this as much as possible, while making it more convenient to consider the default arguments promotion. Fixes https://github.com/llvm/llvm-project/issues/57102 Reviewed By: aaron.ballman, nickdesaulniers, #clang-language-wg Differential Revision: https://reviews.llvm.org/D132568
2022-08-26 19:26:32 +08:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Bug Fixes to C++ Support
^^^^^^^^^^^^^^^^^^^^^^^^
Diagnose extensions in 'offsetof' https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm made very clear that it is an UB having type definitions with in offsetof. Clang supports defining a type as the first argument as a conforming extension due to how many projects use the construct in C99 and earlier to calculate the alignment of a type. GCC also supports defining a type as the first argument. This adds extension warnings and documentation for the functionality Clang explicitly supports. Fixes #57065 Reverts the revert of 39da55e8f548a11f7dadefa73ea73d809a5f1729 Co-authored-by: Yingchi Long <i@lyc.dev> Co-authored-by: Aaron Ballman <aaron@aaronballman.com> Differential Revision: https://reviews.llvm.org/D133574
2023-01-18 08:49:45 -05:00
[clang][Sema] Add checks for validity of default ctor's class (#78898) Fixes #10518 Fixes #67914 Fixes #78388 Also addresses the second example in #49103 This patch is based on suggestion from @cor3ntin in https://github.com/llvm/llvm-project/issues/67914#issuecomment-1896011898
2024-02-09 20:59:02 +04:00
- Fix crash when calling the constructor of an invalid class.
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
(#GH10518) (#GH67914) (#GH78388)
[Clang][Sema] fix crash of attribute transform (#78088) Try to fix [issue](https://github.com/llvm/llvm-project/issues/73619) 1. During transforming `FunctionProtoType`, if `ThisContext` is `nullptr` and `CurrentContext` is `ClassTemplateSpecializationDecl`, Constructor of `CXXThisScopeRAII` and `Sema::getCurrentThisType` won't set `CXXThisTypeOverride` of Sema. This will lead to building `this` in `RebuildCXXThisExpr` with a invalid type(NULL type) and cause crash. 2. During transforming attribute type, if `modifiedType` of attribute type is changed, `EquivalentType` need to be transformed. If `EquivalentType` is `FunctionProtoType`, its `ParamVarDecl` will not be copyed(but parameter num does) and will not be instanced in `TransformFunctionTypeParams` since `ParamVarDecl` is `nullptr`. This will lead to crash in `findInstantiationOf`(can't find the instance of `ParamVarDecl`). This patch tries to fix these issues above. 1. If `CurrentContext` is `ClassTemplateSpecializationDecl`, Use it. 2. Use `EquivalentTypeLoc` instead of `EquivalentType` since it has parameter info. But, if use current `TypeLocBuilder`, it will crash in `TypeLocBuilder::push` since `LastType` is mismatch. Use an auxiliary `TypeLocBuilder` instead and get transformed `EquivalentType`. Co-authored-by: huqizhi <836744285@qq.com>
2024-01-26 14:26:53 +08:00
- Fix crash when using lifetimebound attribute in function with trailing return.
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
(#GH73619)
[concepts] Push a CurContext before substituting into out-of-line constraints for comparison (#79985)
2024-01-31 12:17:41 +08:00
- Addressed an issue where constraints involving injected class types are perceived
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
distinct from its specialization types. (#GH56482)
[Concepts] Traverse the instantiation chain for parameter injection inside a constraint scope (#79568) We preserve the trailing requires-expression during the lambda expression transformation. In order to get those referenced parameters inside a requires-expression properly resolved to the instantiated decls, we intended to inject these 'original' `ParmVarDecls` to the current instantiaion scope, at `Sema::SetupConstraintScope`. The previous approach seems to overlook nested instantiation chains, leading to the crash within a nested lambda followed by a requires clause. This fixes https://github.com/llvm/llvm-project/issues/73418.
2024-01-27 15:42:52 +08:00
- Fixed a bug where variables referenced by requires-clauses inside
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
nested generic lambdas were not properly injected into the constraint scope. (#GH73418)
[concepts] Set up an instantiation scope for constraint expression comparison (#79698) This is a follow-up for the comparison of constraints on out-of-line function template definitions. We require the instantiation of a ParmVarDecl while transforming the expression if that Decl gets referenced by a DeclRefExpr. However, we're not actually performing the class or function template instantiation at the time of such comparison. Therefore, let's map these parameters to themselves so that they get preserved after the substitution. Fixes https://github.com/llvm/llvm-project/issues/74447.
2024-01-30 19:34:52 +08:00
- Fixed a crash where substituting into a requires-expression that refers to function
parameters during the equivalence determination of two constraint expressions.
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
(#GH74447)
[Clang][Sema] fix deducing auto& from const int in template parameters is impossible in partial specializations (#79733) Fix [issue](https://github.com/llvm/llvm-project/issues/77189) AutoType is possible cv qualified. Co-authored-by: huqizhi <836744285@qq.com>
2024-01-29 06:42:52 +08:00
- Fixed deducing auto& from const int in template parameters of partial
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
specializations. (#GH77189)
[Clang][Sema] Fix crash when type used in return statement contains errors (#79788) In Sema in `BuildReturnStmt(...)` when we try to determine is the type is move eligible or copy elidable we don't currently check of the init of the `VarDecl` contain errors or not. This can lead to a crash since we may send a type that is not complete into `getTypeInfo(...)` which does not allow this. This fixes: https://github.com/llvm/llvm-project/issues/63244 https://github.com/llvm/llvm-project/issues/79745
2024-01-29 10:08:09 -08:00
- Fix for crash when using a erroneous type in a return statement.
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
(#GH63244) (#GH79745)
[clang][Sema] Populate function template depth at AddTemplateOverloadCandidate (#80395) This is yet another one-line patch to fix crashes on constraint substitution. ```cpp template <class, class> struct formatter; template <class, class> struct basic_format_context {}; template <typename CharType> concept has_format_function = format(basic_format_context<CharType, CharType>()); template <typename ValueType, typename CharType> requires has_format_function<CharType> struct formatter<ValueType, CharType> { template <typename OutputIt> CharType format(basic_format_context<OutputIt, CharType>); }; ``` In this case, we would build up a `RecoveryExpr` for a call within a constraint expression due to the absence of viable functions. The heuristic algorithm attempted to find such a function inside of a ClassTemplatePartialSpecialization, from which we started to substitute its requires-expression, and it succeeded with a FunctionTemplate such that 1) It has only one parameter, which is dependent. 2) The only one parameter depends on two template parameters. They are, in canonical form, `<template-parameter-1-0>` and `<template-parameter-0-1>` respectively. Before we emit an error, we still want to recover the most viable functions. This goes downhill to deducing template parameters against its arguments, where we would collect the argument type with the same depth as the parameter type into a Deduced set. The size of the set is presumed to be that of function template parameters, which is 1 in this case. However, since we haven't yet properly set the template depth before the dance, we'll end up putting the type for `<template-parameter-0-1>` to the second position of Deduced set, which is unfortunately an access violation! The bug seems to appear since clang 12.0. This fixes [the case](https://github.com/llvm/llvm-project/issues/58548#issuecomment-1287935336).
2024-02-03 16:14:48 +08:00
- Fixed an out-of-bounds error caused by building a recovery expression for ill-formed
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
function calls while substituting into constraints. (#GH58548)
- Fix incorrect code generation caused by the object argument
of ``static operator()`` and ``static operator[]`` calls not being evaluated. (#GH67976)
[Clang][Sema] Fix crash with const qualified member operator new (#80327) We should diagnose a const qualified member operator new but we fail to do so and this leads to crash during debug info generation. The fix is to diagnose this as ill-formed in the front-end. Fixes: https://github.com/llvm/llvm-project/issues/79748
2024-02-02 20:26:54 -08:00
- Fix crash and diagnostic with const qualified member operator new.
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
Fixes (#GH79748)
[concepts] Extract function template pack arguments from the current instantiation if possible (#80594) Before the constraint substitution, we employ `getTemplateInstantiationArgs`, which in turn attempts to inspect `TemplateArgument`s from the function template. For parameter packs from their parent contexts, we used to extract the arguments from the specialization type, in which could result in non-canonical argument types e.g. `PackExpansionType`. This may break the contract that, during a tree transformation, in `TreeTransform::TryExpandParameterPacks`, the corresponding `TemplateArgument`s for an `UnexpandedParameterPack` are expected to be of `Pack` kinds if we're expanding template parameters. Fixes https://github.com/llvm/llvm-project/issues/72557.
2024-02-06 09:59:16 +08:00
- Fixed a crash where substituting into a requires-expression that involves parameter packs
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
during the equivalence determination of two constraint expressions. (#GH72557)
[Clang][Sema] fix outline member function template with default align crash (#80288) Try to fix [issue](https://github.com/llvm/llvm-project/issues/68490 ) and some extented problem. Root cause of current issue is that error handling in instantiation of function parameter with default initialization on sizeof or align expression. When instance an out-of-line template member function, depth of `TemplateTypeParmDecl` in default initialization doesn't change while depth of other template parameter does and this will lead to some template parameter uninstanced. Also, sometime it will leader to wrong instantiation when it uses the template parameter of the template class. Fix it by add template args of context. This will make MultiLevelTemplateArgumentList::getNumLevels matching the depth of template parameter. Testcase with some static_assert demonstrates the template parameter has been instanced correctly. But, the default initialization of lambda expression compiles failed when only checking if the member function is out-of-line. We should check the `PrimaryFunctionTemplateDecl` of the funtion if it's out-of-line. Co-authored-by: huqizhi <836744285@qq.com>
2024-02-03 21:49:09 +08:00
- Fix a crash when specializing an out-of-line member function with a default
parameter where we did an incorrect specialization of the initialization of
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
the default parameter. (#GH68490)
[Clang][Sema] Fix out-of-bounds access (#80978) Trying to compile a C-style variadic member function with an explicit object parameter was crashing in Sema because of an out-of-bounds access. This fixes #80971.
2024-02-07 15:12:15 +01:00
- Fix a crash when trying to call a varargs function that also has an explicit object parameter.
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
Fixes (#GH80971)
- Reject explicit object parameters on `new` and `delete` operators. (#GH82249)
- Fix a crash when trying to call a varargs function that also has an explicit object parameter. (#GH80971)
[Clang][Sema] Abbreviated function templates do not append invented parameters to empty template parameter lists (#80864) According to [dcl.fct] p23: > An abbreviated function template can have a _template-head_. The invented _template-parameters_ are appended to the _template-parameter-list_ after the explicitly declared _template-parameters_. `template<>` is not a _template-head_ -- a _template-head_ must have at least one _template-parameter_. This patch corrects our current behavior of appending the invented template parameters to the innermost template parameter list, regardless of whether it is empty. Example: ``` template<typename T> struct A { void f(auto); }; template<> void A<int>::f(auto); // ok template<> template<> // warning: extraneous template parameter list in template specialization void A<int>::f(auto); ```
2024-02-08 13:04:10 -05:00
- Fixed a bug where abbreviated function templates would append their invented template parameters to
an empty template parameter lists.
[clang] Support `__is_trivially_copyable(int()&)==false` (#81298) IMHO it would be productive to make a similar change for `typeid`, in `ParseCXXTypeid`, in order to improve Clang's error message for https://godbolt.org/z/oKKWxeYra But that might be better done by adding a new DeclaratorContext specifically for TypeidArg, instead of pretending that the argument to `typeid` is a template argument, because I don't know what else that change might affect. Fixes #77585
2024-03-05 12:37:00 +03:30
- Fix parsing of abominable function types inside type traits.
Fixes (`#77585 <https://github.com/llvm/llvm-project/issues/77585>`_)
Consider aggregate bases when checking if an InitListExpr is constant (#80519) This code was correct as written prior to C++17, which allowed bases to appear in the initializer list. This was observable by creating non-constant aggregate initialization at file scope in a compound literal, but since that behavior will change soon if we implement support for dynamic initialization, I also added a unit test for `isConstantInitializer`. This fixes at least one part of issue #80510 . --------- Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
2024-02-08 14:27:14 -08:00
- Clang now classifies aggregate initialization in C++17 and newer as constant
or non-constant more accurately. Previously, only a subset of the initializer
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
elements were considered, misclassifying some initializers as constant. Partially fixes
#GH80510.
- Clang now ignores top-level cv-qualifiers on function parameters in template partial orderings. (#GH75404)
[C++] Fix parsing of _Alignas in local declarations (#81915) We support '_Alignas' from C11 as an extension in C++. However, we were not correctly parsing its use in local variable declarations. This patch addresses that issue.
2024-02-16 07:43:55 -05:00
- No longer reject valid use of the ``_Alignas`` specifier when declaring a
local variable, which is supported as a C11 extension in C++. Previously, it
was only accepted at namespace scope but not at local function scope.
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
- Clang no longer tries to call consteval constructors at runtime when they appear in a member initializer. (#GH82154)
- Fix crash when using an immediate-escalated function at global scope. (#GH82258)
- Correctly immediate-escalate lambda conversion functions. (#GH82258)
[Clang][Parser] Have the depth of the abbreviated generic lambdas inside a requires clause differ from the surrounding generic lambda (#80656) A one-line fix, again : ) This fixes https://github.com/llvm/llvm-project/issues/78524 and the similar example at https://github.com/llvm/llvm-project/issues/78524#issuecomment-1899886951. We previously increased the template depth by one after parsing the attaching requires-clause on a lambda expression. This led to a problem where the 'auto' parameters of nested abbreviated generic lambdas, inside of a requires-expression, had the same depth as the template parameters of the surrounding lambda. Consequently, during the concept-checking stage, we ended up substituting these parameters with the wrong template arguments because they were at different levels.
2024-02-23 09:36:32 +08:00
- Fixed an issue where template parameters of a nested abbreviated generic lambda within
a requires-clause lie at the same depth as those of the surrounding lambda. This,
in turn, results in the wrong template argument substitution during constraint checking.
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
(#GH78524)
[Clang][Sema] Defer instantiation of exception specification until after partial ordering when determining primary template (#82417) Consider the following: ``` struct A { static constexpr bool x = true; }; template<typename T, typename U> void f(T, U) noexcept(T::y); // #1, error: no member named 'y' in 'A' template<typename T, typename U> void f(T, U*) noexcept(T::x); // #2 template<> void f(A, int*) noexcept; // explicit specialization of #2 ``` We currently instantiate the exception specification of all candidate function template specializations when deducting template arguments for an explicit specialization, which results in a error despite `#1` not being selected by partial ordering as the most specialized template. According to [except.spec] p13: > An exception specification is considered to be needed when: > - [...] > - the exception specification is compared to that of another declaration (e.g., an explicit specialization or an overriding virtual function); Assuming that "comparing declarations" means "determining whether the declarations correspond and declare the same entity" (per [basic.scope.scope] p4 and [basic.link] p11.1, respectively), the exception specification does _not_ need to be instantiated until _after_ partial ordering, at which point we determine whether the implicitly instantiated specialization and the explicit specialization declare the same entity (the determination of whether two functions/function templates correspond does not consider the exception specifications). This patch defers the instantiation of the exception specification until a single function template specialization is selected via partial ordering, matching the behavior of GCC, EDG, and MSVC: see https://godbolt.org/z/Ebb6GTcWE.
2024-02-26 09:58:55 -05:00
- Clang no longer instantiates the exception specification of discarded candidate function
templates when determining the primary template of an explicit specialization.
[Clang][Sema] Fix crash when MS dependent base class lookup occurs in an incomplete context (#83024) When compiling the following with `-fms-compatibility`: ``` template<typename T> struct C; // Test lookup with incomplete lookup context template<typename T> auto C<T>::f() -> decltype(x) { } ``` An assert fails because `CXXRecordDecl::hasAnyDependentBases` is called on an incomplete class. This patch ensures we don't perform unqualified lookup into dependent base classes when the lookup context is incomplete.
2024-02-26 14:01:48 -05:00
- Fixed a crash in Microsoft compatibility mode where unqualified dependent base class
lookup searches the bases of an incomplete class.
[Clang] [Sema] Handle placeholders in '.*' expressions (#83103) When analysing whether we should handle a binary expression as an overloaded operator call or a builtin operator, we were calling `checkPlaceholderForOverload()`, which takes care of any placeholders that are not overload sets—which would usually make sense since those need to be handled as part of overload resolution. Unfortunately, we were also doing that for `.*`, which is not overloadable, and then proceeding to create a builtin operator anyway, which would crash if the RHS happened to be an unresolved overload set (due hitting an assertion in `CreateBuiltinBinOp()`—specifically, in one of its callees—in the `.*` case that makes sure its arguments aren’t placeholders). This pr instead makes it so we check for *all* placeholders early if the operator is `.*`. It’s worth noting that, 1. In the `.*` case, we now additionally also check for *any* placeholders (not just non-overload-sets) in the LHS; this shouldn’t make a difference, however—at least I couldn’t think of a way to trigger the assertion with an overload set as the LHS of `.*`; it is worth noting that the assertion in question would also complain if the LHS happened to be of placeholder type, though. 2. There is another case in which we also don’t perform overload resolution—namely `=` if the LHS is not of class or enumeration type after handling non-overload-set placeholders—as in the `.*` case, but similarly to 1., I first couldn’t think of a way of getting this case to crash, and secondly, `CreateBuiltinBinOp()` doesn’t seem to care about placeholders in the LHS or RHS in the `=` case (from what I can tell, it, or rather one of its callees, only checks that the LHS is not a pseudo-object type, but those will have already been handled by the call to `checkPlaceholderForOverload()` by the time we get to this function), so I don’t think this case suffers from the same problem. This fixes #53815. --------- Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
2024-02-27 20:19:44 +01:00
- Fix a crash when an unresolved overload set is encountered on the RHS of a ``.*`` operator.
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
(#GH53815)
[Clang] [Sema] Handle `this` in `__restrict`-qualified member functions properly (#83187) When resolving the type of `this` inside a member function, we were attaching all qualifiers present on the member function to the class type and then making it a pointer; however, `__restrict`, unlike `const` and `volatile`, needs to be attached to the pointer type rather than the pointee type. This fixes #82941, #42411, and #18121.
2024-02-29 17:43:01 +01:00
- In ``__restrict``-qualified member functions, attach ``__restrict`` to the pointer type of
``this`` rather than the pointee type.
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
Fixes (#GH82941), (#GH42411) and (#GH18121).
[Clang] Fix __has_cpp_attribute and C++11 attributes with arguments in C++03 (#83065) The values for `__has_cpp_attribute` don't have to be guarded behind `LangOpts.CPlusPlus` because `__has_cpp_attribute` isn't available if Clang isn't in a C++ mode. Fixes #82995
2024-03-01 15:15:11 +01:00
- Clang now properly reports supported C++11 attributes when using
[Clang][Docs] Simpler syntax for Github links. (#82746) Github links in release notes are often invalid rST, clutter the release notes and are annoying to write. This introduces a sphynx plugin that rewrites `#GH<NUMBER>` to a link to the corresponding issue.
2024-03-04 14:22:51 +01:00
``__has_cpp_attribute`` and parses attributes with arguments in C++03 (#GH82995)
Fix implementation of [temp.param]p14's first sentence. (#83487) The first sentence says: If a template-parameter of a class template, variable template, or alias template has a default template-argument, each subsequent template-parameter shall either have a default template-argument supplied or be a template parameter pack. However, we were only testing for "not a function function template", and referring to an older version of the standard. As far as I can tell, CWG2032 added the variable-template, and the alias-template pre-dates the standard on github. This patch started as a bug fix for #83461 , but ended up fixing a number of similar cases, so those are validated as well.
2024-03-01 07:27:06 -08:00
- Clang now properly diagnoses missing 'default' template arguments on a variety
of templates. Previously we were diagnosing on any non-function template
instead of only on class, alias, and variable templates, as last updated by
[Clang][Docs] Fix issue number Fix typo introduced by 6e36cebc17417f88e70b4e87c9f177036b1443f4
2024-03-04 15:16:46 +01:00
CWG2032. Fixes (#GH83461)
Fix null-deref thanks to an attribute on a global declarator chunk (#83611) This was reported (sort of) in a PR: #77703. The problem is that a declarator 'owns' an attributes allocation via an `AttributePool`. However, this example tries to copy a DeclaratorChunk from one Declarator to another, so when the temporary Declarator goes out of scope, it deletes the attribute it has tried to pass on via the chunk. This patch ensures that we copy the 'ownership' of the attribute correctly, and adds an assert to catch any other casess where this happens. Additionally, this was put in as a bug report, so this Fixes #83611
2024-03-04 09:25:29 -08:00
- Fixed an issue where an attribute on a declarator would cause the attribute to
be destructed prematurely. This fixes a pair of Chromium that were brought to
Fix release note bug reference from bd7bce2c8465e9cb
2024-03-04 09:52:25 -08:00
our attention by an attempt to fix in (#GH77703). Fixes (#GH83385).
[Clang] Fix looking for immediate calls in default arguments. (#80690) Due to improper use of RecursiveASTVisitor. Fixes #80630
2024-03-05 10:04:45 +01:00
- Fix evaluation of some immediate calls in default arguments.
Fixes (#GH80630)
[clang][Sema] Skip the RequiresExprBodyDecls for lambda dependencies (#83997) The dependency of a lambda inside of a `RequiresExprBodyDecl` was previously affected by its parent, e.g., `ClassTemplateSpecializationDecl`. This made the lambda always dependent regardless of the template arguments we had, which caused some crashes on the constraint evaluation later. This fixes https://github.com/llvm/llvm-project/issues/56556, fixes https://github.com/llvm/llvm-project/issues/82849 and a case demonstrated by https://github.com/llvm/llvm-project/issues/49570#issuecomment-1664966972.
2024-03-07 09:49:02 +08:00
- Fixed an issue where the ``RequiresExprBody`` was involved in the lambda dependency
calculation. (#GH56556), (#GH82849).
[clang][Sema] Bugfix for choosing the more specialized overload (#83279) There was a bug in Clang where it couldn't choose which overload candidate was more specialized if it was comparing a member-function to a non-member function. Previously, this was detected as an ambiguity, now Clang chooses correctly. This patch fixes the bug by fully implementing CWG2445 and moving the template transformation described in `[temp.func.order]` paragraph 3 from `isAtLeastAsSpecializedAs()` to `Sema::getMoreSpecializedTemplate()` so we have the transformed parameter list during the whole comparison. Also, to be able to add the correct type for the implicit object parameter `Sema::getMoreSpecializedTemplate()` has new parameters for the object type. Fixes #74494, fixes #82509
2024-03-06 15:03:21 +01:00
- Fix a bug where overload resolution falsely reported an ambiguity when it was comparing
a member-function against a non member function or a member-function with an
explicit object parameter against a member function with no explicit object parameter
when one of the function had more specialized templates.
Fixes (`#82509 <https://github.com/llvm/llvm-project/issues/82509>`_)
and (`#74494 <https://github.com/llvm/llvm-project/issues/74494>`_)
[Clang][Sema] Allow access to a public template alias declaration that refers to friend's private nested type (#83847) This patch attempts to fix https://github.com/llvm/llvm-project/issues/25708 Current access check missed qualifier(`NestedNameSpecifier`) in friend class checking. Add it to `Records` of `EffectiveContext` by changing the `DeclContext` makes `MatchesFriend` work. Co-authored-by: huqizhi <836744285@qq.com>
2024-03-13 08:42:22 +08:00
- Allow access to a public template alias declaration that refers to friend's
private nested type. (#GH25708).
[Clang][Sema] Properly get captured 'this' pointer in lambdas with an explicit object parameter in constant evaluator (#81102) There were some bugs wrt explicit object parameters in lambdas in the constant evaluator: - The code evaluating a `CXXThisExpr` wasn’t checking for explicit object parameters at all and thus assumed that there was no `this` in the current context because the lambda didn’t have one, even though we were in a member function and had captured its `this`. - The code retrieving captures as lvalues *did* account for explicit object parameters, but it did not handle the case of the explicit object parameter being passed by value rather than by reference. This fixes #80997. --------- Co-authored-by: cor3ntin <corentinjabot@gmail.com> Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
2024-03-13 18:49:44 +01:00
- Fixed a crash in constant evaluation when trying to access a
captured ``this`` pointer in a lambda with an explicit object parameter.
Fixes (#GH80997)
[Clang][Sema] Fix a bug on type constraint checking (#84671) Try to fix https://github.com/llvm/llvm-project/issues/84368 When visiting class members in `TemplateDeclInstantiator::VisitClassTemplateDecl` during `Sema::InstantiateClass`, we miss to set attribute of friend declaration if it is(`isFriend` is true). This will lead to `Sema::AreConstraintExpressionsEqual` return false when invoked in `MatchTemplateParameterKind`. Because it makes `Sema::getTemplateInstantiationArgs` returns incorrect template argument(`MultiLevelTemplateArgumentList`). When we handle `CXXRecordDecl` In `Sema::getTemplateInstantiationArgs`, friend declaration(its parent context is `FileContext`) makes us to choose `LexicalDeclContext` not `DeclContext` and this is what we want. Co-authored-by: huqizhi <836744285@qq.com>
2024-03-14 14:24:27 +08:00
- Fix an issue where missing set friend declaration in template class instantiation.
Fixes (#GH84368).
[Concepts] Add Decls from the outer scope of the current lambda for conversion function constraints (#83420) This fixes the case shown by https://github.com/llvm/llvm-project/issues/64808#issuecomment-1929131611. Similar to https://github.com/llvm/llvm-project/commit/f9caa12328b265b77221fe7a310d4504673d814a, we have some calls to constraint checking for a lambda's conversion function while determining the conversion sequence. This patch addresses the problem where the requires-expression within such a lambda references to a Decl outside of the lambda by adding these Decls to the current instantiation scope. I'm abusing the flag `ForOverloadResolution` of CheckFunctionConstraints, which is actually meant to consider the Decls from parent DeclContexts. --------- Co-authored-by: cor3ntin <corentinjabot@gmail.com>
2024-03-16 12:56:11 +08:00
- Fixed a crash while checking constraints of a trailing requires-expression of a lambda, that the
expression references to an entity declared outside of the lambda. (#GH64808)
fix: constexpr bit_cast with empty base classes (#82383) Prior to this commit, clang would fail to produce a constant value for `b` in: ```c++ struct base { }; struct s : base { int z; }; constexpr auto b = std::bit_cast<s>(0x12); ``` e.g. https://godbolt.org/z/srrbTMPq4
2024-03-17 09:35:13 -07:00
- Clang's __builtin_bit_cast will now produce a constant value for records with empty bases. See:
(#GH82383)
[Clang][Sema] Fix a crash in lambda instantiation (#85565) Fix https://github.com/llvm/llvm-project/issues/85343 When build lambda expression in lambda instantiation, `ThisType` is required in `Sema::CheckCXXThisCapture` to build `this` capture. Set `this` type by import `Sema::CXXThisScopeRAII` and it will be used later in lambda expression transformation. Co-authored-by: huqizhi <836744285@qq.com>
2024-03-20 08:33:30 +08:00
- Fix a crash when instantiating a lambda that captures ``this`` outside of its context. Fixes (#GH85343).
[Clang] Raise an error on namespace aliases with qualified names. (#86122)
2024-03-22 19:08:02 -04:00
- Fix an issue where a namespace alias could be defined using a qualified name (all name components
following the first `::` were ignored).
[clang] Fix an out-of-bound crash when checking template partial specializations. (#86794) I found this issue (a separate one) during the investigation of #86757, the crash is similar in substituteParameterMappings, but at different inner places. This was an out-of-bound issue where we access front element in an empty written template argument list to get the instantiation source range. This patch fixes it by adding a proper guard.
2024-03-27 15:31:55 +01:00
- Fix an out-of-bounds crash when checking the validity of template partial specializations. (part of #GH86757).
[clang] Bailout when the substitution of template parameter mapping is invalid. (#86869) Fixes #86757 We missed to handle the invalid case when substituting into the parameter mapping of an constraint during normalization. The constructor of `InstantiatingTemplate` will bail out (no `CodeSynthesisContext` will be added to the instantiation stack) if there was a fatal error, consequently we should stop doing any further template instantiations.
2024-03-28 13:10:02 +01:00
- Fix an issue caused by not handling invalid cases when substituting into the parameter mapping of a constraint. Fixes (#GH86757).
[Clang][Sema] Fix explicit specializations of member function templates with a deduced return type (#86817) Clang erroneously rejects the following: ``` template<typename T> struct A { template<typename U> auto f(); }; template<> template<typename U> auto A<int>::f(); // error: conflicting types for 'f' ``` This happens because the explicit specialization of `f` has its return type replaced with a dependent `AutoType` in `ActOnFunctionDeclarator`, but no such replacement occurs for the implicitly instantiated function template `A<int>::f`. Since the return types don't match, the explicit specialization is diagnosed as an invalid redeclaration. This patch moves the replacement of the return type to `CheckFunctionDeclaration` so it also happens during instantiation. `setObjectOfFriendDecl` will have been called by then, so the `isFriend && CurContext->isDependentContext()` condition is made redundant & removed (as it already happens in `DeclContext::isDependentContext`). `Sema::IsOverload` only checks the _declared_ return type (which isn't changed by the adjustment), so adjusting the return type afterwards should be safe.
2024-04-02 08:35:42 -04:00
- Fixed a bug that prevented member function templates of class templates declared with a deduced return type
from being explicitly specialized for a given implicit instantiation of the class template.
[Clang][Sema] fix crash of attribute transform (#78088) Try to fix [issue](https://github.com/llvm/llvm-project/issues/73619) 1. During transforming `FunctionProtoType`, if `ThisContext` is `nullptr` and `CurrentContext` is `ClassTemplateSpecializationDecl`, Constructor of `CXXThisScopeRAII` and `Sema::getCurrentThisType` won't set `CXXThisTypeOverride` of Sema. This will lead to building `this` in `RebuildCXXThisExpr` with a invalid type(NULL type) and cause crash. 2. During transforming attribute type, if `modifiedType` of attribute type is changed, `EquivalentType` need to be transformed. If `EquivalentType` is `FunctionProtoType`, its `ParamVarDecl` will not be copyed(but parameter num does) and will not be instanced in `TransformFunctionTypeParams` since `ParamVarDecl` is `nullptr`. This will lead to crash in `findInstantiationOf`(can't find the instance of `ParamVarDecl`). This patch tries to fix these issues above. 1. If `CurrentContext` is `ClassTemplateSpecializationDecl`, Use it. 2. Use `EquivalentTypeLoc` instead of `EquivalentType` since it has parameter info. But, if use current `TypeLocBuilder`, it will crash in `TypeLocBuilder::push` since `LastType` is mismatch. Use an auxiliary `TypeLocBuilder` instead and get transformed `EquivalentType`. Co-authored-by: huqizhi <836744285@qq.com>
2024-01-26 14:26:53 +08:00
[clang] Fix crash when inheriting from a cv-qualified type (#70594) This change makes the `assertion` less strict in `debug` builds by stripping qualifiers from the base class and ignoring them. I hope `weakened` assertions don't affect other cases where such `errors` are intended to be `caught` by the compiler. Fixes #35603 Fixes #85256
2024-04-02 21:36:56 +05:30
- Fix crash when inheriting from a cv-qualified type. Fixes:
(`#35603 <https://github.com/llvm/llvm-project/issues/35603>`_)
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Bug Fixes to AST Handling
^^^^^^^^^^^^^^^^^^^^^^^^^
[concepts] Preserve the FoundDecl of ConceptReference properly (#85032) The `ConceptReference`'s `FoundDecl` claims it "can differ from `NamedConcept` when, for example, the concept was found through a `UsingShadowDecl`", but such the contract was not previously respected. Fixes https://github.com/llvm/llvm-project/issues/82628
2024-03-14 10:09:47 +08:00
- Clang now properly preserves ``FoundDecls`` within a ``ConceptReference``. (#GH82628)
Forbid implicit conversion of constraint expression to bool As reported in https://github.com/llvm/llvm-project/issues/54524, and later in https://github.com/llvm/llvm-project/issues/60038, we were not properly implmenting temp.constr.atomic P3. This patch stops implicitly converting constraints to bool, and ensures the Rvalue conversion takes place as needed. Differential Revision: https://reviews.llvm.org/D141954
2023-01-17 11:29:04 -08:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Miscellaneous Bug Fixes
^^^^^^^^^^^^^^^^^^^^^^^
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Miscellaneous Clang Crashes Fixed
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[CUDA][HIP] support __noinline__ as keyword CUDA/HIP programs use __noinline__ like a keyword e.g. __noinline__ void foo() {} since __noinline__ is defined as a macro __attribute__((noinline)) in CUDA/HIP runtime header files. However, gcc and clang supports __attribute__((__noinline__)) the same as __attribute__((noinline)). Some C++ libraries use __attribute__((__noinline__)) in their header files. When CUDA/HIP programs include such header files, clang will emit error about invalid attributes. This patch fixes this issue by supporting __noinline__ as a keyword, so that CUDA/HIP runtime could remove the macro definition. Reviewed by: Aaron Ballman, Artem Belevich Differential Revision: https://reviews.llvm.org/D124866
2022-05-03 14:13:56 -04:00
[Clang] [Sema] Do not crash on dependent or invalid record decls when `-fdump-record-layouts-complete` is passed (#83688) We no longer try to compute and dump the layout of types in cases where that isn’t possible. This fixes #83684 and #83671.
2024-03-04 14:04:35 +01:00
- Do not attempt to dump the layout of dependent types or invalid declarations
when ``-fdump-record-layouts-complete`` is passed.
Fixes (`#83684 <https://github.com/llvm/llvm-project/issues/83684>`_).
[OpenACC] Initial commits to support OpenACC (#70234) Initial commits to support OpenACC. This patchset: adds a clang-command line argument '-fopenacc', and starts to define _OPENACC, albeit to '1' instead of the standardized value (since we don't properly implement OpenACC yet). The OpenACC spec defines `_OPENACC` to be equal to the latest standard implemented. However, since we're not done implementing any standard, we've defined this by default to be `1`. As it is useful to run our compiler against existing OpenACC workloads, we're providing a temporary override flag to change the `_OPENACC` value to be any entirely digit value, permitting testing against any existing OpenACC project. Exactly like the OpenMP parser, the OpenACC pragma parser needs to consume and reprocess the tokens. This patch sets up the infrastructure to do so by refactoring the OpenMP version of this into a more general version that works for OpenACC as well. Additionally, this adds a few diagnostics and token kinds to get us started.
2023-11-17 06:29:02 -08:00
OpenACC Specific Changes
------------------------
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Target Specific Changes
-----------------------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
[Clang] Always use --no-undefined when linking AMDGPU images AMDGPU uses ELF shared libraries to implement their executable device images. One downside to this method is that it disables regular warnings on undefined symbols. This is because shared libraries expect these to be resolves by later loads. However, the GPU images do not support dynamic linking so any undefined symbol is going to cause a runtime error. This patch adds `--no-undefined` to the `ld.lld` invocation to guarantee that undefined symbols are always caught as linking errors rather than runtime errors. Reviewed By: arsenm, MaskRay, #amdgpu Differential Revision: https://reviews.llvm.org/D145941
2023-03-13 09:33:08 -05:00
AMDGPU Support
^^^^^^^^^^^^^^
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
X86 Support
^^^^^^^^^^^
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Arm and AArch64 Support
^^^^^^^^^^^^^^^^^^^^^^^
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
[clang][driver] Allow unaligned access on ARMv7 and higher by default (#82400) ARM's Clang and GCC embedded compilers default to allowing unaligned access for ARMv7+. This patch changes the Clang driver default to match. Users can opt out with `-mno-unaligned-access`. Fixes #59560
2024-02-22 14:26:11 -08:00
- ARMv7+ targets now default to allowing unaligned access, except Armv6-M, and
Armv8-M without the Main Extension. Baremetal targets should check that the
new default will work with their system configurations, since it requires
that SCTLR.A is 0, SCTLR.U is 1, and that the memory in question is
configured as "normal" memory. This brings Clang in-line with the default
settings for GCC and Arm Compiler. Aside from making Clang align with other
compilers, changing the default brings major performance and code size
improvements for most targets. We have not changed the default behavior for
ARMv6, but may revisit that decision in the future. Users can restore the old
behavior with -m[no-]unaligned-access.
[TargetParser][AArch64] Add alias for FEAT_RDM. (#80540) This patch allows using the name "rdma" as an alias for "rdm". The name makes its way to target attributes as well as the command line via the -march and -mcpu options. The motivation was originally to support this in Function Multi Versioning but it also makes sense to align with GCC on the command line.
2024-03-01 21:06:08 +00:00
- An alias identifier (rdma) has been added for targeting the AArch64
Architecture Extension which uses Rounding Doubling Multiply Accumulate
instructions (rdm). The identifier is available on the command line as
a feature modifier for -march and -mcpu as well as via target attributes
like ``target_version`` or ``target_clones``.
Add support for Arm Cortex A78AE CPU (#84485) Add support for Arm Cortex A78AE CPU Technical Reference Manual for Arm Cortex A78AE: https://developer.arm.com/documentation/101779/0003 Fixes #84450
2024-03-08 16:11:36 +00:00
- Support has been added for the following processors (-mcpu identifiers in parenthesis):
* Arm Cortex-A78AE (cortex-a78ae).
[AArch64] Add support for Cortex-A520AE and Cortex-A720AE CPUs (#85401) [AArch64] Add support for Cortex-A520AE and Cortex-A720AE CPUs Cortex-A520AE and Cortex-A720AE are Armv9.2 AArch64 CPUs. Technical Reference Manual for Cortex-A520AE: https://developer.arm.com/documentation/107726/latest/ Technical Reference Manual for Cortex-A720AE: https://developer.arm.com/documentation/102828/latest/
2024-03-19 10:04:51 +00:00
* Arm Cortex-A520AE (cortex-a520ae).
* Arm Cortex-A720AE (cortex-a720ae).
[clang][driver] Allow unaligned access on ARMv7 and higher by default (#82400) ARM's Clang and GCC embedded compilers default to allowing unaligned access for ARMv7+. This patch changes the Clang driver default to match. Users can opt out with `-mno-unaligned-access`. Fixes #59560
2024-02-22 14:26:11 -08:00
[driver] Search for compatible Android runtime directories Android triples include a version number, which makes direct triple comparisons for per-target runtime directory searching not always work. Instead, look for the triple with the highest compatible version number and use that per-target runtime directory instead. This maintains the existing fallback to a triple without any version number, but I'm hoping we can remove that in the future. https://discourse.llvm.org/t/62717 discusses this further. The one remaining triple mismatch after this is that Android armv7 triples usually have an environment of `androideabi`, which Clang normalizes to `android`. If you use the `androideabi` triple when building the runtimes with a per-target runtimes dir, the directory will get created with `androideabi` in its name, but Clang's triple search uses the normalized triple and will look for an `android` directory instead. https://reviews.llvm.org/D140925 will fix that by normalizing triples when creating the per-target runtimes directories as well. Reviewed By: phosek, pirama Differential Revision: https://reviews.llvm.org/D158476
2023-08-31 18:04:56 -07:00
Android Support
^^^^^^^^^^^^^^^
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Windows Support
^^^^^^^^^^^^^^^
[clang] [MinGW] Add the option -fno-auto-import In GCC, the .refptr stubs are only generated for x86_64, and only for code models medium and larger (and medium is the default for x86_64 since this was introduced). They can be omitted for projects that are conscious about performance and size, and don't need automatically importing dll data members, by passing -mcmodel=small. In Clang/LLVM, such .refptr stubs are generated for any potentially symbol reference that might end up autoimported. The .refptr stubs are emitted for three separate reasons: - Without .refptr stubs, undefined symbols are mostly referenced with 32 bit wide relocations. If the symbol ends up autoimported from a different DLL, a 32 bit relative offset might not be enough to reference data in a different DLL, depending on runtime loader layout. - Without .refptr stubs, the runtime pseudo relocation mechanism will need to temporarily make sections read-write-executable if there are such relocations in the text section - On ARM and AArch64, the immediate addressing encoded into instructions isn't in the form of a plain 32 bit relative offset, but is expressed with various bits scattered throughout two instructions - the mingw runtime pseudo relocation mechanism doesn't support updating offsets in that form. If autoimporting is known not to be needed, the user can now compile with -fno-auto-import, avoiding the extra overhead of the .refptr stubs. However, omitting them is potentially fragile as the code might still rely on automatically importing some symbol without the developer knowing. If this happens, linking still usually will succeed, but users may encounter issues at runtime. Therefore, if the new option -fno-auto-import is passed to the compiler when driving linking, it passes the flag --disable-auto-import to the linker, making sure that no symbols actually are autoimported when the generated code doesn't expect it. Differential Revision: https://reviews.llvm.org/D61670
2019-05-08 11:45:26 +03:00
[clang] Add `intrin0.h` header to mimic `intrin0.h` used by MSVC STL for clang-cl (#75711) Fixes https://github.com/llvm/llvm-project/issues/53520. #### Description #### Provide `intrin0.h` to be the minimal set of intrinsics that the MSVC STL requires. The `intrin0.h` header matches the latest header provided by MSVC 1939 which does include some extra intrinsics that the MSVC STL does not use. Inside `BuiltinHeaders.def` I kept the header description as `intrin.h`. If you want me to change those to `intrin0.h` for the moved intrinsics let me know. This should now allow `immintrin.h` to be used with function targets for runtime cpu detection of simd instruction sets without worrying about the compile-time overhead from MSVC STL including `intrin.h` on clang. I still need to figure out how to best update MSVC STL to detect for the presence of `intrin0.h` from clang and to use this header over `intrin.h`. #### Testing #### Built clang locally and ran the test suite. I still need to do a pass over the existing unit tests for the ms intrinsics to make sure there aren't any gaps. Wanted to get this PR up for discussion first. Modified latest MSVC STL from github to point to `intrin0.h` for clang. Wrote some test files that included MSVC STL headers that rely on intrinsics such as `atomic`, `bit` and `vector`. Built the unit tests against x86, arm, aarch64, and x64. #### Benchmarks #### The following include times are based on the x64 target with the modified headers in this PR. These timings were done by using `clang-cl.exe -ftime-trace` and taking the wall time for parsing `intrin.h` and `intrin0.h`. `intrin.h` takes ~897ms to parse. `intrin0.h` takes ~1ms to parse. If there is anything required or a different approach is preferred let me know. I would very much like to move this over the finish line so we can use function targets with clang-cl.
2024-03-19 08:30:54 -04:00
- Clang-cl now supports function targets with intrinsic headers. This allows
for runtime feature detection of intrinsics. Previously under clang-cl
``immintrin.h`` and similar intrinsic headers would only include the intrinsics
if building with that feature enabled at compile time, e.g. ``avxintrin.h``
would only be included if AVX was enabled at compile time. This was done to work
around include times from MSVC STL including ``intrin.h`` under clang-cl.
Clang-cl now provides ``intrin0.h`` for MSVC STL and therefore all intrinsic
features without requiring enablement at compile time.
Fixes: (`#53520 <https://github.com/llvm/llvm-project/issues/53520>`_)
- Improved compile times with MSVC STL. MSVC provides ``intrin0.h`` which is a
header that only includes intrinsics that are used by MSVC STL to avoid the
use of ``intrin.h``. MSVC STL when compiled under clang uses ``intrin.h``
instead. Clang-cl now provides ``intrin0.h`` for the same compiler throughput
purposes as MSVC. Clang-cl also provides ``yvals_core.h`` to redefine
``_STL_INTRIN_HEADER`` to expand to ``intrin0.h`` instead of ``intrin.h``.
This also means that if all intrinsic features are enabled at compile time
including STL headers will no longer slow down compile times since ``intrin.h``
is not included from MSVC STL.
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
LoongArch Support
^^^^^^^^^^^^^^^^^
[docs] Add llvm & clang release notes for LoongArch (#79097)
2024-01-23 15:27:06 +08:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
RISC-V Support
^^^^^^^^^^^^^^
[clang][RISCV] Change default abi with f extension but without d extension (#73489) Now we have default abi lp64 for rv64if and ilp32 for rv32if, which is different with riscv-gnu-toolchain. In https://github.com/riscv-collab/riscv-gnu-toolchain/blob/8e9fb09a0c4b1e566492ee6f42e8c1fa5ef7e0c2/configure#L3385 when have f and not d, it prefers lp64f/ilp32f but no soft float. This patch tries to make their behaviors consistent.
2023-12-15 11:16:05 +08:00
[Docs] Fix documentation build. Missing ending `` after c92ad411f2f94d8521cd18abcb37285f9a390ecb
2024-01-25 19:19:28 -08:00
- ``__attribute__((rvv_vector_bits(N)))`` is now supported for RVV vbool*_t types.
[RISCV] Support RISC-V Profiles in -march option (#76357) This PR implements the draft https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/36. Currently, we replace specified profile in `-march` with standard arch string. This is recommitted as 66f88de was reverted because of failures caused by lacking `--target` option.
2024-03-22 18:24:23 +08:00
- Profile names in ``-march`` option are now supported.
Recommit "[RISCV] Support __riscv_v_fixed_vlen for vbool types. (#76551)" Test updated to expect i8 gep. Original message: This adopts a similar behavior to AArch64 SVE, where bool vectors are represented as a vector of chars with 1/8 the number of elements. This ensures the vector always occupies a power of 2 number of bytes. A consequence of this is that vbool64_t, vbool32_t, and vool16_t can only be used with a vector length that guarantees at least 8 bits.
2024-01-25 09:39:29 -08:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
CUDA/HIP Language Changes
^^^^^^^^^^^^^^^^^^^^^^^^^
[WebAssembly] Update supported features in the generic CPU configuration Enable sign-ext and mutable-globals in -mcpu=generic. This makes these features enabled by default. These features are all [finished proposals], and all major wasm engines support them. [finished proposals]: https://github.com/WebAssembly/proposals/blob/main/finished-proposals.md Differential Revision: https://reviews.llvm.org/D125728
2022-10-18 10:50:37 -07:00
[NFC] Eliminate trailing white space causing CI build failure (#84632) To resolve the following issue in the CI build: ``` *** Checking for trailing whitespace left in Clang source files *** + grep -rnI '[[:blank:]]$' clang/lib clang/include clang/docs clang/docs/ReleaseNotes.rst:412:- PTX is no longer included by default when compiling for CUDA. Using + echo '*** Trailing whitespace has been found in Clang source files as described above ***' *** Trailing whitespace has been found in Clang source files as described above *** + exit 1 ```
2024-03-09 20:47:29 +03:30
- PTX is no longer included by default when compiling for CUDA. Using
[CUDA] Include PTX in non-RDC mode using the new driver (#84367) Summary: The old driver embed PTX in rdc-mode and so does the `nvcc` compiler. The new drivers currently does not do this, so we should keep it consistent in this case. This simply requires adding the assembler output as an input to the offloading action that gets fed to fatbin.
2024-03-07 16:53:41 -06:00
``--cuda-include-ptx=all`` will return the old behavior.
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
CUDA Support
^^^^^^^^^^^^
Clang: Change the default DWARF version to 5 (except on platforms that already opt in to specific versions - SCE, Android, and Darwin using DWARFv4 explicitly, for instance)
2022-01-23 20:45:25 -08:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
AIX Support
^^^^^^^^^^^
[Clang][AArch64] Support AArch64 target(..) attribute formats. This adds support under AArch64 for the target("..") attributes. The current parsing is very X86-shaped, this patch attempts to bring it line with the GCC implementation from https://gcc.gnu.org/onlinedocs/gcc/AArch64-Function-Attributes.html#AArch64-Function-Attributes. The supported formats are: - "arch=<arch>" strings, that specify the architecture features for a function as per the -march=arch+feature option. - "cpu=<cpu>" strings, that specify the target-cpu and any implied atributes as per the -mcpu=cpu+feature option. - "tune=<cpu>" strings, that specify the tune-cpu cpu for a function as per -mtune. - "+<feature>", "+no<feature>" enables/disables the specific feature, for compatibility with GCC target attributes. - "<feature>", "no-<feature>" enabled/disables the specific feature, for backward compatibility with previous releases. To do this, the parsing of target attributes has been moved into TargetInfo to give the target the opportunity to override the existing parsing. The only non-aarch64 change should be a minor alteration to the error message, specifying using "CPU" to describe the cpu, not "architecture", and the DuplicateArch/Tune from ParsedTargetAttr have been combined into a single option. Differential Revision: https://reviews.llvm.org/D133848
2022-10-01 15:40:59 +01:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
WebAssembly Support
^^^^^^^^^^^^^^^^^^^
[ARM] Allow selecting hard-float ABI in integer-only MVE. Armv8.1-M can be configured to support the integer subset of the MVE vector instructions, and no floating point. In that situation, the FP and vector registers still exist, and so do the load, store and move instructions that transfer data in and out of them. So there's no reason the hard floating point ABI can't be supported, and you might reasonably want to use it, for the sake of intrinsics-based code passing explicit MVE vector types between functions. But the selection of the hard float ABI in the backend was gated on Subtarget->hasVFP2Base(), which is false in the case of integer MVE and no FP. As a result, you'd silently get the soft float ABI even if you deliberately tried to select it, e.g. with clang options such as --target=arm-none-eabi -mfloat-abi=hard -march=armv8.1m.main+nofp+mve The hard float ABI should have been gated on the weaker condition Subtarget->hasFPRegs(), because the only requirement for being able to pass arguments in the FP registers is that the registers themselves should exist. I haven't added a new test, because changing the existing CodeGen/Thumb2/float-ops.ll test seemed sufficient. But I've added a comment explaining why the results are expected to be what they are. Reviewed By: lenary Differential Revision: https://reviews.llvm.org/D142703
2023-01-31 17:31:33 +00:00
[Clang] [AVR] Fix USHRT_MAX for 16-bit int. For AVR, the definition of USHRT_MAX overflows. Reviewed By: aaron.ballman, #clang-language-wg Differential Revision: https://reviews.llvm.org/D144218
2022-02-06 08:20:54 -05:00
AVR Support
^^^^^^^^^^^
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
DWARF Support in Clang
----------------------
[Clang][LLVM] Enable __arithmetic_fence and fprotect-parens on AArch64 Enable __arithmetic_fence and fprotect-parens on AArch64. Test plan: ninja check-clang check-clang-tools check-llvm Differential revision: https://reviews.llvm.org/D143781
2023-02-13 18:29:16 +00:00
Making the code compliant to the documentation about Floating Point support default values for C/C++. FPP-MODEL=PRECISE enables FFP-CONTRACT(FMA is enabled). Fix for https://bugs.llvm.org/show_bug.cgi?id=50222
2021-11-09 09:35:25 -05:00
Floating Point Support in Clang
-------------------------------
[clang] Add fixed point precision macros (#81207) This defines the builtin macros specified in `7.18a.3 Precision macros` of ISO/IEC TR 18037:2008. These are the `__*__` versions of them and the formal definitions in stdfix.h can use them.
2024-02-14 14:11:56 -08:00
Fixed Point Support in Clang
----------------------------
- Support fixed point precision macros according to ``7.18a.3`` of
`ISO/IEC TR 18037:2008 <https://standards.iso.org/ittf/PubliclyAvailableStandards/c051126_ISO_IEC_TR_18037_2008.zip>`_.
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
AST Matchers
------------
[clang] Fix isInStdNamespace for Decl flagged extern c++ (#81776) The MSVC STL implementation declares multiple classes using: ```cpp namespace std { extern "C++" class locale { ... }; } ``` `isInStdNamespace` uses the first DeclContext to check whether a Decl is inside the `std` namespace. Here, the first DeclContext of the `locale` Decl is a LinkageSpecDecl so the method will return false. We need to skip this LinkageSpecDecl to find the first DeclContext of type Namespace and actually check whether we're in the `std` namespace.
2024-02-15 14:55:25 +01:00
- ``isInStdNamespace`` now supports Decl declared with ``extern "C++"``.
[clang][ASTMatcher] Add matchers for isExplicitObjectMemberFunction() (#84446) Note that this patch will be necessary to fix `forEachArgumentWithParam()` and `forEachArgumentWithParamType()` matchers for deducing "this"; which is my true motivation. There the bug is that with explicit obj params, one should not adjust the number of arguments in presence of `CXXMethodDecls`, and this causes a mismatch there mapping the argument to the wrong param. But, I'll come back there once we have this matcher.
2024-03-08 13:57:27 +01:00
- Add ``isExplicitObjectMemberFunction``.
[clang][ASTMatchers] Fix forEachArgumentWithParam* for deducing "this" operator calls (#84887) This is a follow-up commit of #84446. In this patch, I demonstrate that `forEachArgumentWithParam` and `forEachArgumentWithParamType` did not correctly handle the presence of the explicit object parameter for operator calls. Prior to this patch, the matcher would skip the first (and only) argument of the operator call if the explicit object param was used. Note that I had to move the definition of `isExplicitObjectMemberFunction`, to be declared before the matcher I fix to be visible. I also had to do some gymnastics for passing the language standard version command-line flags to the invocation as `matchAndVerifyResultTrue` wasn't really considered for non-c++11 code. See the that it always prepends `-std=gnu++11` to the command-line arguments. I workarounded it by accepting extra args, which get appended, thus possibly overriding the hardcoded arguments. I'm not sure if this qualifies for backporting to clang-18 (probably not because its not a crash, but a semantic problem), but I figure it might be useful for some vendors (like us). But we are also happy to cherry-pick this fix to downstream. Let me know if you want this to be backported or not. CPP-5074
2024-03-12 17:31:22 +01:00
- Fixed ``forEachArgumentWithParam`` and ``forEachArgumentWithParamType`` to
not skip the explicit object parameter for operator calls.
[clang] Fix isInStdNamespace for Decl flagged extern c++ (#81776) The MSVC STL implementation declares multiple classes using: ```cpp namespace std { extern "C++" class locale { ... }; } ``` `isInStdNamespace` uses the first DeclContext to check whether a Decl is inside the `std` namespace. Here, the first DeclContext of the `locale` Decl is a LinkageSpecDecl so the method will return false. We need to skip this LinkageSpecDecl to find the first DeclContext of type Namespace and actually check whether we're in the `std` namespace.
2024-02-15 14:55:25 +01:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
clang-format
------------
[clang-format] Rename option AlwaysBreakTemplateDeclarations (#81093) Drop the "Always" prefix to remove the self-contradiction.
2024-02-09 19:53:04 -08:00
- ``AlwaysBreakTemplateDeclarations`` is deprecated and renamed to
``BreakTemplateDeclarations``.
[clang-format] Rename option AlwaysBreakAfterReturnType. (#80827) Changes the option to BreakAfterReturnType option, with a more relevant name, deprecating and replacing AlwaysBreakAfterReturnType. Following up on #78010.
2024-02-13 14:58:33 +10:30
- ``AlwaysBreakAfterReturnType`` is deprecated and renamed to
``BreakAfterReturnType``.
[clang-format] Rename option AlwaysBreakTemplateDeclarations (#81093) Drop the "Always" prefix to remove the self-contradiction.
2024-02-09 19:53:04 -08:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
libclang
--------
SONAME introduce option CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION This reverts commit bc39d7bdd4977a953b2e102f8f7eb479ad78984e. rename CLANG_SONAME to LIBCLANG_SOVERSION [clang][cmake] introduce option CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION Differential Revision: https://reviews.llvm.org/D132486
2022-08-25 08:35:46 +02:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
Static Analyzer
---------------
[analyzer][docs] Add CSA release notes We'll soon branch off, and start releasing clang-17. Here is a patch, adjusting the release notes for what we achieved since the last release. I used this command to inspect the interesting commits: ``` git log --oneline llvmorg-16.0.0..llvm/main \ clang/{lib/StaticAnalyzer,include/clang/StaticAnalyzer} | \ grep -v NFC | grep -v -i revert ``` This filters in CSA directories and filters out NFC and revert commits. Given that in the release-notes, we usually don't put links to commits, I'll remove them from this patch as well. I just put them there to make it easier to review for you. I tried to group the changes into meaningful chunks, and dropped some of the uninteresting commits. I've also dropped the commits that were backported to clang-16. Check out how it looks, and propose changes like usual. --- FYI the `ninja docs-clang-html` produces the html docs, including the `ReleaseNotes`. And the produced artifact will be at `build/tools/clang/docs/html/ReleaseNotes.html`. Differential Revision: https://reviews.llvm.org/D155445
2023-07-24 08:26:54 +02:00
[clang][analyzer] Fix crash in loop unrolling (#82089) StaticAnalyzer didn't check if the variable is declared in `CompoundStmt` under `SwitchStmt`, which make static analyzer reach root without finding the declaration. Fixes #68819 --------- Co-authored-by: Balazs Benics <benicsbalazs@gmail.com>
2024-03-14 16:16:40 +08:00
- Fixed crashing on loops if the loop variable was declared in switch blocks
but not under any case blocks if ``unroll-loops=true`` analyzer config is
set. (#GH68819)
[analyzer] Support C++23 static operator calls (#84972) Made by following: https://github.com/llvm/llvm-project/pull/83585#issuecomment-1980340866 Thanks for the details Tomek! CPP-5080
2024-03-22 12:04:44 +01:00
- Support C++23 static operator calls. (#GH84972)
[clang][analyzer] Fix crash in loop unrolling (#82089) StaticAnalyzer didn't check if the variable is declared in `CompoundStmt` under `SwitchStmt`, which make static analyzer reach root without finding the declaration. Fixes #68819 --------- Co-authored-by: Balazs Benics <benicsbalazs@gmail.com>
2024-03-14 16:16:40 +08:00
[analyzer][docs] Update the release notes for llvm-18 (#76446) This PR prepares the release notes of the Clang Static Analyzer for the llvm-18 release branch, due in about a week. See the regular [release schedule](https://llvm.org/docs/HowToReleaseLLVM.html#annual-release-schedule). This patch was written after examining the relevant Static Analyzer commits since the last release. Have a look at the commits, and provide feedback if I missed anything interesting. Note that the release notes is not meant to be an exhaustive list of the changes, but rather a curated list of the relevant changes that might interest our stakeholders, such as tool vendors based on top of CSA or users with custom checkers. See the relevant commits by using this command: ``` git log --oneline llvmorg-18-init..llvm/main clang/{lib/StaticAnalyzer,include/clang/StaticAnalyzer} | grep -v NFC | grep -v -i revert ```
2023-12-28 15:48:59 +01:00
New features
^^^^^^^^^^^^
Crash and bug fixes
^^^^^^^^^^^^^^^^^^^
Improvements
^^^^^^^^^^^^
Support C++20 Modules in clang-repl (#79261) This comes from when I playing around clang-repl with moduels : ) I succeeded to import std with https://libcxx.llvm.org/Modules.html and calling `std::printf` after this patch. I want to put the documentation part to https://clang.llvm.org/docs/StandardCPlusPlusModules.html in a separate commit.
2024-01-24 15:45:05 +08:00
- Support importing C++20 modules in clang-repl.
Add a release note for TypeLoc::dump() support; NFC This amends 8d1b1c9b97de557299e8148a79d756c1e8d9b7eb which added the functionality the release note refers to.
2024-01-31 10:43:39 -05:00
- Added support for ``TypeLoc::dump()`` for easier debugging, and improved
textual and JSON dumping for various ``TypeLoc``-related nodes.
[analyzer][docs] Update the release notes for llvm-18 (#76446) This PR prepares the release notes of the Clang Static Analyzer for the llvm-18 release branch, due in about a week. See the regular [release schedule](https://llvm.org/docs/HowToReleaseLLVM.html#annual-release-schedule). This patch was written after examining the relevant Static Analyzer commits since the last release. Have a look at the commits, and provide feedback if I missed anything interesting. Note that the release notes is not meant to be an exhaustive list of the changes, but rather a curated list of the relevant changes that might interest our stakeholders, such as tool vendors based on top of CSA or users with custom checkers. See the relevant commits by using this command: ``` git log --oneline llvmorg-18-init..llvm/main clang/{lib/StaticAnalyzer,include/clang/StaticAnalyzer} | grep -v NFC | grep -v -i revert ```
2023-12-28 15:48:59 +01:00
Moved checkers
^^^^^^^^^^^^^^
[clang][msan] Turn on -fsanitize-memory-param-retval by default This eagerly reports use of undef values when passed to noundef parameters or returned from noundef functions. This also decreases binary sizes under msan. To go back to the previous behavior, pass `-fno-sanitize-memory-param-retval`. Reviewed By: vitalybuka, MaskRay Differential Revision: https://reviews.llvm.org/D134669
2022-09-26 17:41:37 -07:00
.. _release-notes-sanitizers:
Sanitizers
----------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
[Sanitizer] Support -fwrapv with -fsanitize=signed-integer-overflow (#82432) Clang has a `signed-integer-overflow` sanitizer to catch arithmetic overflow; however, most of its instrumentation [fails to apply](https://godbolt.org/z/ee41rE8o6) when `-fwrapv` is enabled; this is by design. The Linux kernel enables `-fno-strict-overflow` which implies `-fwrapv`. This means we are [currently unable to detect signed-integer wrap-around](https://github.com/KSPP/linux/issues/26). All the while, the root cause of many security vulnerabilities in the Linux kernel is [arithmetic overflow](https://cwe.mitre.org/data/definitions/190.html). To work around this and enhance the functionality of `-fsanitize=signed-integer-overflow`, we instrument signed arithmetic even if the signed overflow behavior is defined. Co-authored-by: Justin Stitt <justinstitt@google.com>
2024-02-21 13:00:08 -08:00
- ``-fsanitize=signed-integer-overflow`` now instruments signed arithmetic even
when ``-fwrapv`` is enabled. Previously, only division checks were enabled.
Users with ``-fwrapv`` as well as a sanitizer group like
``-fsanitize=undefined`` or ``-fsanitize=integer`` enabled may want to
manually disable potentially noisy signed integer overflow checks with
``-fno-sanitize=signed-integer-overflow``
[cfi][CodeGen] Call SetLLVMFunctionAttributes{,ForDefinition} on __cf… (#78253) …i_check This causes __cfi_check, just as __cfi_check_fail, to get the proper target-specific attributes, in particular uwtable for unwind table generation. Previously, nounwind attribute could be inferred for __cfi_check, which caused it to lose its unwind table even with -funwind-table option. ~~ Huawei RRI, OS Lab Co-authored-by: Nikolai Kholiavin <kholiavin.nikolai@huawei-partners.com>
2024-03-27 03:25:33 +03:00
- ``-fsanitize=cfi -fsanitize-cfi-cross-dso`` (cross-DSO CFI instrumentation)
now generates the ``__cfi_check`` function with proper target-specific
attributes, for example allowing unwind table generation.
[python] Expose clang_Location_isInSystemHeader Add is_in_system_header property for Location class. Corresponding unit test was also added. Differential Revision: https://reviews.llvm.org/D147414
2023-04-04 09:21:04 -04:00
Python Binding Changes
----------------------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
[libclang/python] Expose Rewriter to the python binding (#77269) Exposes `CXRewriter` API to the python binding as `class Rewriter`.
2024-01-29 11:19:34 -05:00
- Exposed `CXRewriter` API as `class Rewriter`.
Add some missing Kinds to libclang python bindings (#85571) Add some Kinds existing in Index.h but missing in cindex.py.
2024-03-18 22:13:10 +08:00
- Add some missing kinds from Index.h (CursorKind: 149-156, 272-320, 420-437.
TemplateArgumentKind: 5-9. TypeKind: 161-175 and 178).
[libclang/python] Expose Rewriter to the python binding (#77269) Exposes `CXRewriter` API to the python binding as `class Rewriter`.
2024-01-29 11:19:34 -05:00
[Clang] [Parser] Support [[omp::assume]] (#84582) This pr implements the `[[omp::assume]]` spelling for the `__attribute__((assume))` attribute. It does not change anything about how that attribute is handled by the rest of Clang.
2024-03-12 13:42:43 +01:00
OpenMP Support
--------------
- Added support for the `[[omp::assume]]` attribute.
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
Additional Information
======================
A wide variety of additional information is available on the `Clang web
page <https://clang.llvm.org/>`_. The web page contains versions of the
clang/release notes: s/Subversion/git/
2020-03-22 22:18:40 +01:00
API documentation which are up-to-date with the Git version of
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
the source code. You can access versions of these documents specific to
this release by going into the "``clang/docs/``" directory in the Clang
tree.
If you have any questions or comments about Clang, please feel free to
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
contact us on the `Discourse forums (Clang Frontend category)
Update references to Discourse instead of the mailing lists. Update the references to the old Mailman mailing lists to point to Discourse forums. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D128766
2022-07-01 14:07:48 -07:00
<https://discourse.llvm.org/c/clang/6>`_.
Reference in New Issue Copy Permalink