maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages 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.

321 lines
12 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-02 15:13:01 +08:00
===========================================
Clang |release| |ReleaseNotesTitle|
===========================================
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08: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-02 15:13:01 +08:00
.. only:: PreRelease
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08: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-02 15: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
`the Download Page <https://releases.llvm.org/download.html>`_.
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08: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-02 15: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-14 05:46:33 +08: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
documentation <https://llvm.org/docs/ReleaseNotes.html>`_. All LLVM
releases may be downloaded from the `LLVM releases web
site <https://llvm.org/releases/>`_.
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>`_.
Note that if you are reading this file from a Git checkout or the
main Clang web page, this document applies to the *next* release, not
the current one. To see the release notes for a specific release, please
see the `releases page <https://llvm.org/releases/>`_.
[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-02 15: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-14 05:46:33 +08: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.
Major New Features
------------------
[clang] Never wrap a nullptr in CXXNewExpr::getArraySize() Otherwise callers of these functions have to check both the return value for and the contents of the returned llvm::Optional. Fixes #53742 Differential Revision: https://reviews.llvm.org/D119525
2022-02-11 15:27:33 +08:00
Bug Fixes
Fix underlining length; NFC
2022-05-06 20:47:19 +08:00
---------
Diagnose use of _Noreturn on a struct/union field C99 6.7.4p2 clarifies that a function specifier can only be used in the declaration of a function. _Noreturn is a function specifier, so it is a constraint violation to write it on a structure or union field, but we missed that case. Fixes #56800
2022-07-30 01:16:10 +08:00
- Fixes an accepts-invalid bug in C when using a ``_Noreturn`` function
specifier on something other than a function declaration. This fixes
`Issue 56800 <https://github.com/llvm/llvm-project/issues/56800>`_.
[SemaCXX] Validate destructor is valid for dependent classes We didn't check that a destructor's name matches the directly enclosing class if the class was dependent. I enabled the check we already had for non-dependent types, which seems to work. Added appropriate tests. Fixes GitHub issue #56772 Reviewed By: erichkeane Differential Revision: https://reviews.llvm.org/D130936
2022-08-02 04:47:30 +08:00
- Fix `#56772 <https://github.com/llvm/llvm-project/issues/56772>`_ - invalid
destructor names were incorrectly accepted on template classes.
[clang] Short-circuit trivial constructors when evaluating arrays VisitCXXConstructExpr() will later do something similar, but for large arrays, we should try to do it once an not for every element. Fixes #56774 Differential Revision: https://reviews.llvm.org/D130791
2022-07-29 22:12:49 +08:00
- Improve compile-times with large dynamic array allocations with trivial
constructors. This fixes
[clang][NFC] Try to fix the docs build
2022-08-03 16:51:34 +08:00
`Issue 56774 <https://github.com/llvm/llvm-project/issues/56774>`_.
Error instead of assert when making a _BitInt vector We already correctly rejected: typedef __attribute__((vector_size(16))) _BitInt(4) Ty; but we would assert with: typedef __attribute__((ext_vector_type(4))) _BitInt(4) Ty; Now we issue the same error in both cases.
2022-08-04 02:05:09 +08:00
- No longer assert/miscompile when trying to make a vectorized ``_BitInt`` type
using the ``ext_vector_type`` attribute (the ``vector_size`` attribute was
already properly diagnosing this case).
[clang][sema] Fix collectConjunctionTerms() Consider: A == 5 && A != 5 IfA is 5, the old collectConjunctionTerms() would call itself again for the LHS (which it ignores), then the RHS (which it also ignores) and then just return without ever adding anything to the Terms array. Differential Revision: https://reviews.llvm.org/D131070
2022-08-03 23:05:07 +08:00
- Fix clang not properly diagnosing the failing subexpression when chained
binary operators are used in a ``static_assert`` expression.
[clang] Consider array filler in MaybeElementDependentArrayfiller() Any InitListExpr may have an array filler and since we may be evaluating the array filler as well, we need to take into account that the array filler expression might make the InitListExpr element dependent. Fixes https://github.com/llvm/llvm-project/issues/56016 Differential Revision: https://reviews.llvm.org/D131155
2022-08-04 18:53:06 +08:00
- Fix a crash when evaluating a multi-dimensional array's array filler
expression is element-dependent. This fixes
`Issue 50601 <https://github.com/llvm/llvm-project/issues/56016>`_.
Fix crash-on-valid with consteval temporary construction through list initialization Clang currently crashes when lowering a consteval list initialization of a temporary. This is partially working around an issue in the template instantiation code (TreeTransform::TransformCXXTemporaryObjectExpr()) that does not yet know how to handle list initialization of temporaries in all cases. However, it's also helping reduce fragility by ensuring we always have a valid QualType when trying to emit a constant expression during IR generation. Fixes #55871 Differential Revision: https://reviews.llvm.org/D131194
2022-08-12 01:42:47 +08:00
- Fixed a crash-on-valid with consteval evaluation of a list-initialized
constructor for a temporary object. This fixes
`Issue 55871 <https://github.com/llvm/llvm-project/issues/55871>`_.
[clang] fix frontend crash when evaluating type trait Before this patch type traits are checked in Parser, so use type traits directly did not cause assertion faults. However if type traits are initialized from a template, we didn't perform arity checks before evaluating. This patch moves arity checks from Parser to Sema, and performing arity checks in Sema actions, so type traits get checked corretly. Crash input: ``` template<class... Ts> bool b = __is_constructible(Ts...); bool x = b<>; ``` After this patch: ``` clang/test/SemaCXX/type-trait-eval-crash-issue-57008.cpp:5:32: error: type trait requires 1 or more arguments; have 0 arguments template<class... Ts> bool b = __is_constructible(Ts...); ^~~~~~~~~~~~~~~~~~ clang/test/SemaCXX/type-trait-eval-crash-issue-57008.cpp:6:10: note: in instantiation of variable template specialization 'b<>' requested here bool x = b<>; ^ 1 error generated. ``` See https://godbolt.org/z/q39W78hsK. Fixes https://github.com/llvm/llvm-project/issues/57008 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D131423
2022-08-12 02:14:09 +08:00
- Fix `#57008 <https://github.com/llvm/llvm-project/issues/57008>`_ - Builtin
C++ language extension type traits instantiated by a template with unexpected
number of arguments cause an assertion fault.
[clang] fix missing initialization of original number of expansions When expanding undeclared function parameters, we should initialize the original number of expansions, if known, before trying to expand them, otherwise a length mismatch with an outer pack might not be diagnosed. Fixes PR56094. Signed-off-by: Matheus Izvekov <mizvekov@gmail.com> Differential Revision: https://reviews.llvm.org/D131802
2022-08-13 03:50:30 +08:00
- Fix multi-level pack expansion of undeclared function parameters.
This fixes `Issue 56094 <https://github.com/llvm/llvm-project/issues/56094>`_.
[Sema] fix false -Wcomma being emitted from void returning functions Fixes https://github.com/llvm/llvm-project/issues/57151 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D131892
2022-08-15 22:35:39 +08:00
- Fix `#57151 <https://github.com/llvm/llvm-project/issues/57151>`_.
``-Wcomma`` is emitted for void returning functions.
Missing tautological compare warnings due to unary operators The patch mainly focuses on the no warnings for -Wtautological-compare. It work fine for the positive numbers but doesn't for the negative numbers. This is because the warning explicitly checks for an IntegerLiteral AST node, but -1 is represented by a UnaryOperator with an IntegerLiteral sub-Expr. Fixes #42918 Differential Revision: https://reviews.llvm.org/D130510
2022-08-19 22:46:29 +08:00
- ``-Wtautological-compare`` missed warnings for tautological comparisons
involving a negative integer literal. This fixes
`Issue 42918 <https://github.com/llvm/llvm-project/issues/42918>`_.
[Clang] Fix crash in coverage of if consteval. Clang crashes when encountering an `if consteval` statement. This is the minimum fix not to crash. The fix is consistent with the current behavior of if constexpr, which does generate coverage data for the discarded branches. This is of course not correct and a better solution is needed for both if constexpr and if consteval. See https://github.com/llvm/llvm-project/issues/54419. Fixes #57377 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D132723
2022-08-26 16:20:12 +08:00
- Fix a crash when generating code coverage information for an
``if consteval`` statement. This fixes
`Issue 57377 <https://github.com/llvm/llvm-project/issues/57377>`_.
[Clang] Fix assert in Sema::LookupTemplateName so that it does not attempt an unconditional cast to TagType In Sema::LookupTemplateName(...) seeks to assert that the ObjectType is complete or being defined. If the type is incomplete it will attempt to unconditionally cast it to a TagType and not all incomplete types are a TagType. For example the type could be void or it could be an IncompleteArray. This change adds an additional check to confirm it is a TagType before attempting to check if it is incomplete or being defined Differential Revision: https://reviews.llvm.org/D132712
2022-08-27 00:12:29 +08:00
- Fix assert that triggers a crash during template name lookup when a type was
incomplete but was not also a TagType. This fixes
`Issue 57387 <https://github.com/llvm/llvm-project/issues/57387>`_.
[clang][Parse] Fix crash when emitting template diagnostic This was passing a 6 to the diagnostic engine, which the diagnostic message didn't handle. Add the new value to the diagnosic message, remove an unused value and add a test. This fixes https://github.com/llvm/llvm-project/issues/57415 Differential Revision: https://reviews.llvm.org/D132821
2022-08-29 12:51:09 +08:00
- Fix a crash when emitting a concept-related diagnostic. This fixes
`Issue 57415 <https://github.com/llvm/llvm-project/issues/57415>`_.
[Clang] Fix crash in coverage of if consteval. Clang crashes when encountering an `if consteval` statement. This is the minimum fix not to crash. The fix is consistent with the current behavior of if constexpr, which does generate coverage data for the discarded branches. This is of course not correct and a better solution is needed for both if constexpr and if consteval. See https://github.com/llvm/llvm-project/issues/54419. Fixes #57377 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D132723
2022-08-26 16:20:12 +08:00
[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-13 03:49:01 +08:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
Improvements to Clang's diagnostics
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[Clang] Diagnose ill-formed constant expression when setting a non fixed enum to a value outside the range of the enumeration values DR2338 clarified that it was undefined behavior to set the value outside the range of the enumerations values for an enum without a fixed underlying type. We should diagnose this with a constant expression context. Differential Revision: https://reviews.llvm.org/D130058
2022-07-29 06:26:15 +08:00
- Clang will now correctly diagnose as ill-formed a constant expression where an
enum without a fixed underlying type is set to a value outside the range of
[Clang] Allow downgrading to a warning the diagnostic for setting a non fixed enum to a value outside the range of the enumeration values In D130058 we diagnose the undefined behavior of setting the value outside the range of the enumerations values for an enum without a fixed underlying type. Based on feedback we will provide users to the ability to downgrade this diagnostic to a waring to allow for a transition period. We expect to turn this diagnostic to an error in the next release. Differential Revision: https://reviews.llvm.org/D131307
2022-08-09 06:17:34 +08:00
the enumeration's values. Due to the extended period of time this bug was
present in major C++ implementations (including Clang), this error has the
ability to be downgraded into a warning (via: -Wno-error=enum-constexpr-conversion)
to provide a transition period for users. This diagnostic is expected to turn
into an error-only diagnostic in the next Clang release. Fixes
[Clang] Diagnose ill-formed constant expression when setting a non fixed enum to a value outside the range of the enumeration values DR2338 clarified that it was undefined behavior to set the value outside the range of the enumerations values for an enum without a fixed underlying type. We should diagnose this with a constant expression context. Differential Revision: https://reviews.llvm.org/D130058
2022-07-29 06:26:15 +08:00
`Issue 50055: <https://github.com/llvm/llvm-project/issues/50055>`_.
[clang] format string checking for conpile-time evaluated str literal This patch enhances clang's ability to check compile-time determinable string literals as format strings, and can give FixIt hints at literals (unlike gcc). Issue https://github.com/llvm/llvm-project/issues/55805 mentiond two compile-time string cases. And this patch partially fixes one. ``` constexpr const char* foo() { return "%s %d"; } int main() { printf(foo(), "abc", "def"); return 0; } ``` This patch enables clang check format string for this: ``` <source>:4:24: warning: format specifies type 'int' but the argument has type 'const char *' [-Wformat] printf(foo(), "abc", "def"); ~~~~~ ^~~~~ <source>:2:42: note: format string is defined here constexpr const char *foo() { return "%s %d"; } ^~ %s 1 warning generated. ``` Reviewed By: aaron.ballman Signed-off-by: YingChi Long <me@inclyc.cn> Differential Revision: https://reviews.llvm.org/D130906
2022-08-03 10:07:31 +08:00
- Clang will now check compile-time determinable string literals as format strings.
[clang][docs] use `Fixes` instead of `This fixes` in ReleaseNotes [NFC]
2022-08-07 12:42:15 +08:00
Fixes `Issue 55805: <https://github.com/llvm/llvm-project/issues/55805>`_.
[Sema] -Wformat: support C23 format specifier %b %B Close #56885: WG14 N2630 added %b to fprintf/fscanf and recommended %B for fprintf. This patch teaches -Wformat %b for the printf/scanf family of functions and %B for the printf family of functions. glibc 2.35 and latest Android bionic added %b/%B printf support. From https://www.openwall.com/lists/libc-coord/2022/07/ no scanf support is available yet. Like GCC, we don't test library support. GCC 12 -Wformat -pedantic emits a warning: > warning: ISO C17 does not support the ‘%b’ gnu_printf format [-Wformat=] The behavior is not ported. Note: `freebsd_kernel_printf` uses %b differently. Reviewed By: aaron.ballman, dim, enh Differential Revision: https://reviews.llvm.org/D131057
2022-08-05 01:26:31 +08:00
- ``-Wformat`` now recognizes ``%b`` for the ``printf``/``scanf`` family of
functions and ``%B`` for the ``printf`` family of functions. Fixes
`Issue 56885: <https://github.com/llvm/llvm-project/issues/56885>`_.
Fix -Wbitfield-constant-conversion on 1-bit signed bitfield A one-bit signed bit-field can only hold the values 0 and -1; this corrects the diagnostic behavior accordingly. Fixes #53253 Differential Revision: https://reviews.llvm.org/D131255
2022-08-09 23:42:39 +08:00
- ``-Wbitfield-constant-conversion`` now diagnoses implicit truncation when 1 is
assigned to a 1-bit signed integer bitfield. This fixes
`Issue 53253 <https://github.com/llvm/llvm-project/issues/53253>`_.
Default implicit function pointer conversions diagnostic to be an error Implicitly converting between incompatible function pointers in C is currently a default-on warning (it is an error in C++). However, this is very poor security posture. A mismatch in parameters or return types, or a mismatch in calling conventions, etc can lead to exploitable security vulnerabilities. Rather than allow this unsafe practice with a warning, this patch strengthens the warning to be an error (while still allowing users the ability to disable the error or the warning entirely to ease migration). Users should either ensure the signatures are correctly compatible or they should use an explicit cast if they believe that's more reasonable. Differential Revision: https://reviews.llvm.org/D131351
2022-08-11 01:52:33 +08:00
- ``-Wincompatible-function-pointer-types`` now defaults to an error in all C
language modes. It may be downgraded to a warning with
``-Wno-error=incompatible-function-pointer-types`` or disabled entirely with
``-Wno-implicit-function-pointer-types``.
[clang][sema] Print more information about failed static assertions For failed static assertions, try to take the expression apart and print useful information about why it failed. In particular, look at binary operators and print the compile-time evaluated value of the LHS/RHS. Differential Revision: https://reviews.llvm.org/D130894
2022-08-01 20:12:32 +08:00
- Clang will now print more information about failed static assertions. In
particular, simple static assertion expressions are evaluated to their
compile-time value and printed out if the assertion fails.
[clang] Improve diagnostics for uninitialized constexpr variables Instead of complaining about default initialization, tell users that constexpr variables need to be initialized by a constant expression. Differential Revision: https://reviews.llvm.org/D131662
2022-08-11 17:22:00 +08:00
- Diagnostics about uninitialized ``constexpr`` varaibles have been improved
to mention the missing constant initializer.
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 21:17:14 +08:00
- Correctly diagnose a future keyword if it exist as a keyword in the higher
language version and specifies in which version it will be a keyword. This
supports both c and c++ language.
[clang] Improve diagnostics for expansion length mismatch When checking parameter packs for expansion, instead of basing the diagnostic for length mismatch for outer parameters only on the known number of expansions, we should also analyze SubstTemplateTypeParmPackType and SubstNonTypeTemplateParmPackExpr for unexpanded packs, so we can emit a diagnostic pointing to a concrete outer parameter. Signed-off-by: Matheus Izvekov <mizvekov@gmail.com> Differential Revision: https://reviews.llvm.org/D128095
2022-06-18 04:29:27 +08:00
- When diagnosing multi-level pack expansions of mismatched lengths, Clang will
now, in most cases, be able to point to the relevant outer parameter.
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 21:17:14 +08:00
Fix the Sphinx build bot This addresses an accidental break from 41667a8b9b624e282e7c08fadf7091223728d1c1
2022-08-26 22:04:06 +08: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 21:17:14 +08:00
[misexpect] Re-implement MisExpect Diagnostics Reimplements MisExpect diagnostics from D66324 to reconstruct its original checking methodology only using MD_prof branch_weights metadata. New checks rely on 2 invariants: 1) For frontend instrumentation, MD_prof branch_weights will always be populated before llvm.expect intrinsics are lowered. 2) for IR and sample profiling, llvm.expect intrinsics will always be lowered before branch_weights are populated from the IR profiles. These invariants allow the checking to assume how the existing branch weights are populated depending on the profiling method used, and emit the correct diagnostics. If these invariants are ever invalidated, the MisExpect related checks would need to be updated, potentially by re-introducing MD_misexpect metadata, and ensuring it always will be transformed the same way as branch_weights in other optimization passes. Frontend based profiling is now enabled without using LLVM Args, by introducing a new CodeGen option, and checking if the -Wmisexpect flag has been passed on the command line. Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D115907
2022-04-02 06:03:48 +08:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
Non-comprehensive list of changes in this release
Fix clang Sphinx build bot
2022-03-25 19:13:26 +08:00
-------------------------------------------------
[docs] Add blank lines to help Sphinx parse nested bullets.
2022-05-06 06:57:17 +08:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
New Compiler Flags
------------------
Deprecated Compiler Flags
-------------------------
Modified Compiler Flags
-----------------------
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 22:23:02 +08:00
Removed Compiler Flags
-------------------------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
New Pragmas in Clang
--------------------
- ...
Attribute Changes in Clang
--------------------------
[clang] Add support for __attribute__((guard(nocf))) To support using Control Flow Guard with mingw-w64, Clang needs to accept `__declspec(guard(nocf))` also for the GNU target. Since mingw has `#define __declspec(a) __attribute__((a))` as built-in, the simplest solution is to accept `__attribute__((guard(nocf)))` to be compatible with MSVC and Clang's msvc target. As a side effect, this also adds `[[clang::guard(nocf)]]` for C++. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D132302
2022-08-24 04:08:05 +08:00
- Added support for ``__attribute__((guard(nocf)))`` and C++-style
``[[clang::guard(nocf)]]``, which is equivalent to ``__declspec(guard(nocf))``
when using the MSVC environment. This is to support enabling Windows Control
Flow Guard checks with the ability to disable them for specific functions when
[clang] Make guard(nocf) attribute available only for Windows Control Flow Guard is only supported on Windows target, therefore there is no point to make it an accepted attribute for other targets. Reviewed By: rnk, aaron.ballman Differential Revision: https://reviews.llvm.org/D132661
2022-08-29 16:27:27 +08:00
using the MinGW environment. This attribute is only available for Windows
targets.
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
[Clang] Implement function attribute nouwtable To have finer control of IR uwtable attribute generation. For target code generation, IR nounwind and uwtable may have some interaction. However, for frontend, there are no semantic interactions so the this new `nouwtable` is marked "SimpleHandler = 1". Differential Revision: https://reviews.llvm.org/D132592
2022-08-25 03:24:54 +08:00
- Introduced a new function attribute ``__attribute__((nouwtable))`` to suppress
LLVM IR ``uwtable`` function attribute.
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
Windows Support
---------------
[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-03 05:06:04 +08:00
AIX Support
-----------
[AIX][clang][driver] Check the command string to the linker for exportlist opts Summary: Some of code in the patch are contributed by David Tenty. 1. We currently only check driver Wl options and don't check for the plain -b, -Xlinker or other options which get passed through to the linker when we decide whether to run llvm-nm --export-symbols, so we may run it in situations where we wouldn't if the user had used the equivalent -Wl, prefixed options. If we run the export list utility when the user has specified an export list, we could export more symbols than they intended. 2. Add a new functionality to allow redirecting the stdin, stdout, stderr of individual Jobs, if redirects are set for the Job use them, otherwise fall back to the global Compilation redirects if any. Reviewers: David Tenty, Fangrui Song, Steven Wan Differential Revision: https://reviews.llvm.org/D119147
2022-08-30 22:38:38 +08:00
* When using `-shared`, the clang driver now invokes llvm-nm to create an
export list if the user doesn't specify one via linker flag or pass an
alternative export control option.
[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-03 05:06:04 +08:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
C Language Changes in Clang
---------------------------
Implement WG14 N2764 the [[noreturn]] attribute This adds support for http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2764.pdf, which was adopted at the Feb 2022 WG14 meeting. That paper adds [[noreturn]] and [[_Noreturn]] to the list of supported attributes in C2x. These attributes have the same semantics as the [[noreturn]] attribute in C++. The [[_Noreturn]] attribute was added as a deprecated feature so that translation units which include <stdnoreturn.h> do not get an error on use of [[noreturn]] because the macro expands to _Noreturn. Users can use -Wno-deprecated-attributes to silence the diagnostic. Use of <stdnotreturn.h> or the noreturn macro were both deprecated. Users can define the _CLANG_DISABLE_CRT_DEPRECATION_WARNINGS macro to suppress the deprecation diagnostics coming from the header file.
2022-02-14 22:33:48 +08:00
C2x Feature Support
-------------------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
C++ Language Changes in Clang
-----------------------------
[Clang] follow-up D128745, use ClangABICompat15 instead of ClangABICompat14 Since the patch missed release 15.x and will be included in release 16.x. Also, simplify related tests. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D132414
2022-08-24 01:25:02 +08:00
- Implemented DR692, DR1395 and DR1432. Use the ``-fclang-abi-compat=15`` option
[c++] implements DR692, DR1395 and tentatively DR1432, about partial ordering of variadic template partial specialization or function template DR692 handles two cases: pack expansion (for class/var template) and function parameter pack. The former needs DR1432 as a fix, and the latter needs DR1395 as a fix. However, DR1432 has not yet made a wording change. so I made a tentative fix for DR1432 with the same spirit as DR1395. Reviewed By: aaron.ballman, erichkeane, #clang-language-wg Differential Revision: https://reviews.llvm.org/D128745
2022-08-12 03:53:41 +08:00
to get the old partial ordering behavior regarding packs.
clang: libstdc++ LWM is 4.8.3 Document oldest libstdc++ as 4.8.3, remove a hack for a 4.6 issue. Differential Revision: https://reviews.llvm.org/D100465
2021-04-14 19:18:23 +08:00
C++20 Feature Support
^^^^^^^^^^^^^^^^^^^^^
[Concepts] Implement overload resolution for destructors (P0848) This patch implements a necessary part of P0848, the overload resolution for destructors. It is now possible to overload destructors based on constraints, and the eligible destructor will be selected at the end of the class. The approach this patch takes is to perform the overload resolution in Sema::ActOnFields and to mark the selected destructor using a new property in FunctionDeclBitfields. CXXRecordDecl::getDestructor is then modified to use this property to return the correct destructor. This closes https://github.com/llvm/llvm-project/issues/45614. Reviewed By: #clang-language-wg, erichkeane Differential Revision: https://reviews.llvm.org/D126194
2022-06-17 01:52:12 +08:00
[Clang][C++20] Support capturing structured bindings in lambdas This completes the implementation of P1091R3 and P1381R1. This patch allow the capture of structured bindings both for C++20+ and C++17, with extension/compat warning. In addition, capturing an anonymous union member, a bitfield, or a structured binding thereof now has a better diagnostic. We only support structured bindings - as opposed to other kinds of structured statements/blocks. We still emit an error for those. In addition, support for structured bindings capture is entirely disabled in OpenMP mode as this needs more investigation - a specific diagnostic indicate the feature is not yet supported there. Note that the rest of P1091R3 (static/thread_local structured bindings) was already implemented. at the request of @shafik, i can confirm the correct behavior of lldb wit this change. Fixes https://github.com/llvm/llvm-project/issues/54300 Fixes https://github.com/llvm/llvm-project/issues/54300 Fixes https://github.com/llvm/llvm-project/issues/52720 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D122768
2022-03-30 20:27:44 +08:00
- Support capturing structured bindings in lambdas
(`P1091R3 <https://wg21.link/p1091r3>`_ and `P1381R1 <https://wg21.link/P1381R1>`).
This fixes issues `GH52720 <https://github.com/llvm/llvm-project/issues/52720>`_,
`GH54300 <https://github.com/llvm/llvm-project/issues/54300>`_,
`GH54301 <https://github.com/llvm/llvm-project/issues/54301>`_,
and `GH49430 <https://github.com/llvm/llvm-project/issues/49430>`_.
Handle explicitly defaulted consteval special members. Followup patch for D128083 Previously, using a non-consteval constructor from an consteval constructor would code generates the consteval constructor. Example ``` template <typename T> struct S { T i; consteval S() = default; }; struct Foo { Foo() {} }; void func() { S<Foo> three; // incorrectly accepted by clang. } ``` This happened because clang erroneously disregards `consteval` specifier for a `consteval explicitly defaulted special member functions in a class template` if it has dependent data members without a `consteval default constructor`. According to ``` C++14 [dcl.constexpr]p6 (CWG DR647/CWG DR1358): If the instantiated template specialization of a constexpr function template or member function of a class template would fail to satisfy the requirements for a constexpr function or constexpr constructor, that specialization is still a constexpr function or constexpr constructor, even though a call to such a function cannot appear in a constant expression. ``` Therefore the `consteval defaulted constructor of a class template` should be considered `consteval` even if the data members' default constructors are not consteval. Keeping this constructor `consteval` allows complaining while processing the call to data member constructors. (Same applies for other special member functions). This works fine even when we have more than one default constructors since we process the constructors after the templates are instantiated. This does not address initialization issues raised in [2602](https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2602) and compiler divergence seen in https://godbolt.org/z/va9EMvvMe Fixes: https://github.com/llvm/llvm-project/issues/51593 Differential Revision: https://reviews.llvm.org/D131479
2022-08-09 18:05:26 +08:00
- Consider explicitly defaulted constexpr/consteval special member function
template instantiation to be constexpr/consteval even though a call to such
a function cannot appear in a constant expression.
(C++14 [dcl.constexpr]p6 (CWG DR647/CWG DR1358))
Do not evaluate dependent immediate invocations We deferred the evaluation of dependent immediate invocations in https://reviews.llvm.org/D119375 until instantiation. We should also not consider them referenced from a non-consteval context. Fixes: https://github.com/llvm/llvm-project/issues/55601 ``` template<typename T> class Bar { consteval static T x() { return 5; } public: Bar() : a(x()) {} private: int a; }; Bar<int> g(); ``` Is now accepted by clang. Previously it errored with: `cannot take address of consteval function 'x' outside of an immediate invocation Bar() : a(x()) {}` Differential Revision: https://reviews.llvm.org/D132031
2022-08-17 22:44:41 +08:00
- Correctly defer dependent immediate function invocations until template instantiation.
This fixes `GH55601 <https://github.com/llvm/llvm-project/issues/55601>`_.
[Clang] Implement P0848 (Conditionally Trivial Special Member Functions) This patch implements P0848 in Clang. During the instantiation of a C++ class, in `Sema::ActOnFields`, we evaluate constraints for all the SMFs and compare the constraints to compute the eligibility. We defer the computation of the type's [copy-]trivial bits from addedMember to the eligibility computation, like we did for destructors in D126194. `canPassInRegisters` is modified as well to better respect the ineligibility of functions. Note: Because of the non-implementation of DR1734 and DR1496, I treat deleted member functions as 'eligible' for the purpose of [copy-]triviallity. This is unfortunate, but I couldn't think of a way to make this make sense otherwise. Reviewed By: #clang-language-wg, cor3ntin, aaron.ballman Differential Revision: https://reviews.llvm.org/D128619
2022-08-26 05:51:06 +08:00
- Implemented "Conditionally Trivial Special Member Functions" (`P0848 <https://wg21.link/p0848r3>`_).
Note: The handling of deleted functions is not yet compliant, as Clang
does not implement `DR1496 <https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1496>`_
and `DR1734 <https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1734>`_.
[clang] NFC. Small tweak to release notes Forgotten in the last patch.
2022-08-26 16:17:44 +08:00
- Class member variables are now in scope when parsing a ``requires`` clause. Fixes
[clang] Add cxx scope if needed for requires clause. Fixes issue #55216. Patch by Luke Nihlen! (luken@google.com, luken-google@) Reviewed By: #clang-language-wg, aaron.ballman Differential Revision: https://reviews.llvm.org/D132503
2022-08-26 15:52:06 +08:00
`GH55216 <https://github.com/llvm/llvm-project/issues/55216>`_.
[Clang][C++20] Support capturing structured bindings in lambdas This completes the implementation of P1091R3 and P1381R1. This patch allow the capture of structured bindings both for C++20+ and C++17, with extension/compat warning. In addition, capturing an anonymous union member, a bitfield, or a structured binding thereof now has a better diagnostic. We only support structured bindings - as opposed to other kinds of structured statements/blocks. We still emit an error for those. In addition, support for structured bindings capture is entirely disabled in OpenMP mode as this needs more investigation - a specific diagnostic indicate the feature is not yet supported there. Note that the rest of P1091R3 (static/thread_local structured bindings) was already implemented. at the request of @shafik, i can confirm the correct behavior of lldb wit this change. Fixes https://github.com/llvm/llvm-project/issues/54300 Fixes https://github.com/llvm/llvm-project/issues/54300 Fixes https://github.com/llvm/llvm-project/issues/52720 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D122768
2022-03-30 20:27:44 +08:00
PotentiallyEvaluatedContext in a ImmediateFunctionContext. Body of `consteval` should be in an `ImmediateFunctionContext` instead of `ConstantEvaluated`. PotentiallyEvaluated expressions in Immediate functions are in a `ImmediateFunctionContext` as well. Fixes https://github.com/llvm/llvm-project/issues/51182 Original divergence: https://godbolt.org/z/vadGT5j6f Differential Revision: https://reviews.llvm.org/D132659
2022-08-25 22:05:50 +08:00
- Correctly set expression evaluation context as 'immediate function context' in
consteval functions.
Typo fix in Release notes.
2022-08-26 20:34:55 +08:00
This fixes `GH51182 <https://github.com/llvm/llvm-project/issues/51182>`
[Clang][C++20] Support capturing structured bindings in lambdas This completes the implementation of P1091R3 and P1381R1. This patch allow the capture of structured bindings both for C++20+ and C++17, with extension/compat warning. In addition, capturing an anonymous union member, a bitfield, or a structured binding thereof now has a better diagnostic. We only support structured bindings - as opposed to other kinds of structured statements/blocks. We still emit an error for those. In addition, support for structured bindings capture is entirely disabled in OpenMP mode as this needs more investigation - a specific diagnostic indicate the feature is not yet supported there. Note that the rest of P1091R3 (static/thread_local structured bindings) was already implemented. at the request of @shafik, i can confirm the correct behavior of lldb wit this change. Fixes https://github.com/llvm/llvm-project/issues/54300 Fixes https://github.com/llvm/llvm-project/issues/54300 Fixes https://github.com/llvm/llvm-project/issues/52720 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D122768
2022-03-30 20:27:44 +08:00
clang: libstdc++ LWM is 4.8.3 Document oldest libstdc++ as 4.8.3, remove a hack for a 4.6 issue. Differential Revision: https://reviews.llvm.org/D100465
2021-04-14 19:18:23 +08:00
C++2b Feature Support
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
^^^^^^^^^^^^^^^^^^^^^
[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-04 02:13:56 +08:00
CUDA/HIP Language Changes in Clang
----------------------------------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
Objective-C Language Changes in Clang
-------------------------------------
OpenCL C Language Changes in Clang
----------------------------------
...
ABI Changes in Clang
--------------------
OpenMP Support in Clang
-----------------------
[OpenMP][Docs] Remove old 14.0 release information Summary: This patch removes the OpenMP sections in the release notes. These will be filled once the release is close and implementations are finalized.
2022-04-19 20:45:51 +08:00
...
[Clang][Docs] Add documention for new OpenMP offloading driver This patch adds more documentation for the OpenMP offloading driver. This includes a new file that describes the overall pipeline becuase that was not previously explained in full elsewhere. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D118815
2022-02-03 02:06:55 +08:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
CUDA Support in Clang
---------------------
- ...
[RISCV] Change how mtune aliases are implemented. The previous implementation translated from names like sifive-7-series to sifive-7-rv32 or sifive-7-rv64. This also required sifive-7-rv32 and sifive-7-rv64 to be valid CPU names. As those are not real CPUs it doesn't make sense to accept them in -mcpu. This patch does away with the translation and adds sifive-7-series directly to RISCV.td. Removing sifive-7-rv32 and sifive-7-rv64. sifive-7-series is only allowed in -mtune. I've also added "rocket" to RISCV.td but have not removed rocket-rv32 or rocket-rv64. To prevent -mcpu=sifive-7-series or -mcpu=rocket being used with llc, I've added a Feature32Bit to all rv32 CPUs. And made it an error to have an rv32 triple without Feature32Bit. sifive-7-series and rocket do not have Feature32Bit or Feature64Bit set so the user would need to provide -mattr=+32bit or -mattr=+64bit along with the -mcpu to avoid the error. SiFive no longer names their newer products with 3, 5, or 7 series. Instead we have p200 series, x200 series, p500 series, and p600 series. Following the previous behavior would require a sifive-p500-rv32 and sifive-p500-rv64 in order to support -mtune=sifive-p500-series. There is currently no p500 product, but it could start getting confusing if there was in the future. I'm open to hearing alternatives for how to achieve my main goal of removing sifive-7-rv32/rv64 as a CPU name. Reviewed By: reames Differential Revision: https://reviews.llvm.org/D131708
2022-08-19 05:39:37 +08:00
RISC-V Support in Clang
-----------------------
- ``sifive-7-rv32`` and ``sifive-7-rv64`` are no longer supported for `-mcpu`.
Use `sifive-e76`, `sifive-s76`, or `sifive-u74` instead.
[X86] Enable constexpr on POPCNT intrinsics (PR31446) This is a first step patch to enable constexpr support and testing to a large number of x86 intrinsics. All I've done here is provide a DEFAULT_FN_ATTRS_CONSTEXPR variant to our existing DEFAULT_FN_ATTRS tag approach that adds constexpr on c++ builds. The clang cuda headers do something similar. I've started with POPCNT mainly as its tiny and are wrappers to generic __builtin_* intrinsics which already act as constexpr. Differential Revision: https://reviews.llvm.org/D86229
2020-08-21 04:37:51 +08:00
X86 Support in Clang
--------------------
[X86] Support ``-mindirect-branch-cs-prefix`` for call and jmp to indirect thunk This is to address feature request from https://github.com/ClangBuiltLinux/linux/issues/1665 Reviewed By: nickdesaulniers, MaskRay Differential Revision: https://reviews.llvm.org/D130754
2022-07-29 17:47:49 +08:00
- Support ``-mindirect-branch-cs-prefix`` for call and jmp to indirect thunk.
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-24 12:45:25 +08:00
DWARF Support in Clang
----------------------
[AArch64]Enabling Cortex-A510 Support This patch enables support for Cortex-A510 CPUs. Reviewed By: MarkMurrayARM, dmgreen Differential Revision: https://reviews.llvm.org/D109825
2021-10-15 21:29:57 +08:00
Arm and AArch64 Support in Clang
--------------------------------
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 22:35:25 +08:00
Floating Point Support in Clang
-------------------------------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
Internal API Changes
--------------------
Build System Changes
--------------------
AST Matchers
------------
clang-format
------------
[clang-extdef-mapping] Directly process .ast files When doing CTU analysis setup you pre-compile .cpp to .ast and then you run clang-extdef-mapping on the .cpp file as well. This is a pretty slow process since we have to recompile the file each time. With this patch you can now run clang-extdef-mapping directly on the .ast file. That saves a lot of time. I tried this on llvm/lib/AsmParser/Parser.cpp and running extdef-mapping on the .cpp file took 5.4s on my machine. While running it on the .ast file it took 2s. This can save a lot of time for the setup phase of CTU analysis. Reviewed By: martong Differential Revision: https://reviews.llvm.org/D128704
2022-07-05 19:45:32 +08:00
clang-extdef-mapping
--------------------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
libclang
--------
Expose QualType::getUnqualifiedType in libclang The method is now wrapped by clang_getUnqualifiedType. A declaration for clang_getUnqualifiedType was added to clang-c/Index.h to expose it to user of the library. An implementation for clang_getUnqualifiedType was introduced in CXType.cpp that wraps the equivalent method of the underlying QualType of a CXType. An export symbol was added to libclang.map under the new version entry LLVM_16. A test was added to LibclangTest.cpp that tests the removal of qualifiers for some CXTypes. Differential Revision: https://reviews.llvm.org/D132749
2022-08-29 20:16:18 +08:00
- Introduced the new function `clang_getUnqualifiedType`, which mimics
the behavior of `QualType::getUnqualifiedType` for `CXType`.
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 14:35:46 +08:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
Static Analyzer
---------------
Reland "[analyzer] Deprecate `-analyzer-store region` flag" I'm trying to remove unused options from the `Analyses.def` file, then merge the rest of the useful options into the `AnalyzerOptions.def`. Then make sure one can set these by an `-analyzer-config XXX=YYY` style flag. Then surface the `-analyzer-config` to the `clang` frontend; After all of this, we can pursue the tablegen approach described https://discourse.llvm.org/t/rfc-tablegen-clang-static-analyzer-engine-options-for-better-documentation/61488 In this patch, I'm proposing flag deprecations. We should support deprecated analyzer flags for exactly one release. In this case I'm planning to drop this flag in `clang-16`. In the clang frontend, now we won't pass this option to the cc1 frontend, rather emit a warning diagnostic reminding the users about this deprecated flag, which will be turned into error in clang-16. Unfortunately, I had to remove all the tests referring to this flag, causing a mass change. I've also added a test for checking this warning. I've seen that `scan-build` also uses this flag, but I think we should remove that part only after we turn this into a hard error. Reviewed By: martong Differential Revision: https://reviews.llvm.org/D126215
2022-06-14 15:20:41 +08:00
[analyzer] Drop deprecated flags As proposed in D126215 (ffe7950ebc62380c3afc7c71f454a1db3f6f5c76), I'm dropping the `-analyzer-store` and `-analyzer-opt-analyze-nested-blocks` clang frontend flags. I'm also dropping the corresponding commandline handlers of `scanbuild`. This behavior is planned to be part of `clang-16`. Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D132289
2022-08-24 00:39:21 +08:00
- Removed the deprecated ``-analyzer-store`` and
``-analyzer-opt-analyze-nested-blocks`` analyzer flags.
``scanbuild`` was also updated accordingly.
Passing these flags will result in a hard error.
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
.. _release-notes-ubsan:
Undefined Behavior Sanitizer (UBSan)
------------------------------------
Core Analysis Improvements
==========================
- ...
New Issues Found
================
- ...
Python Binding Changes
----------------------
The following methods have been added:
- ...
Significant Known Problems
==========================
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-23 05:18:40 +08: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-14 05:46:33 +08: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
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-02 05:07:48 +08:00
contact us on the Discourse forums (Clang Frontend category)
<https://discourse.llvm.org/c/clang/6>`_.