aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Sema/SemaCast.cpp
AgeCommit message (Collapse)AuthorFilesLines
2023-01-12[clang] Reland parenthesized aggregate init patchesAlan Zhao1-0/+1
This commit relands the patches for implementing P0960R3 and P1975R0, which describe initializing aggregates via a parenthesized list. The relanded commits are: * 40c52159d3ee - P0960R3 and P1975R0: Allow initializing aggregates from a parenthesized list of values * c77a91bb7ba7 - Remove overly restrictive aggregate paren init logic * 32d7aae04fdb - Fix a clang crash on invalid code in C++20 mode This patch also fixes a crash in the original implementation. Previously, if the input tried to call an implicitly deleted copy or move constructor of a union, we would then try to initialize the union by initializing it's first element with a reference to a union. This behavior is incorrect (we should fail to initialize) and if the type of the first element has a constructor with a single template typename parameter, then Clang will explode. This patch fixes that issue by checking that constructor overload resolution did not result in a deleted function before attempting parenthesized aggregate initialization. Additionally, this patch also includes D140159, which contains some minor fixes made in response to code review comments in the original implementation that were made after that patch was submitted. Co-authored-by: Sheng <ox59616e@gmail.com> Fixes #54040, Fixes #59675 Reviewed By: ilya-biryukov Differential Revision: https://reviews.llvm.org/D141546
2023-01-04[clang] Revert parentesized aggregate initalization patchesAlan Zhao1-1/+0
This feature causes clang to crash when compiling Chrome - see https://crbug.com/1405031 and https://github.com/llvm/llvm-project/issues/59675 Revert "[clang] Fix a clang crash on invalid code in C++20 mode." This reverts commit 32d7aae04fdb58e65a952f281ff2f2c3f396d98f. Revert "[clang] Remove overly restrictive aggregate paren init logic" This reverts commit c77a91bb7ba793ec3a6a5da3743ed55056291658. Revert "[clang][C++20] P0960R3 and P1975R0: Allow initializing aggregates from a parenthesized list of values" This reverts commit 40c52159d3ee337dbed14e4c73b5616ea354c337.
2022-12-14[clang][C++20] P0960R3 and P1975R0: Allow initializing aggregates from a ↵Alan Zhao1-0/+1
parenthesized list of values This patch implements P0960R3, which allows initialization of aggregates via parentheses. As an example: ``` struct S { int i, j; }; S s1(1, 1); int arr1[2](1, 2); ``` This patch also implements P1975R0, which fixes the wording of P0960R3 for single-argument parenthesized lists so that statements like the following are allowed: ``` S s2(1); S s3 = static_cast<S>(1); S s4 = (S)1; int (&&arr2)[] = static_cast<int[]>(1); int (&&arr3)[2] = static_cast<int[2]>(1); ``` This patch was originally authored by @0x59616e and completed by @ayzhao. Fixes #54040, Fixes #54041 Co-authored-by: Sheng <ox59616e@gmail.com> Full write up : https://discourse.llvm.org/t/c-20-rfc-suggestion-desired-regarding-the-implementation-of-p0960r3/63744 Reviewed By: ilya-biryukov Differential Revision: https://reviews.llvm.org/D129531
2022-10-26[Clang][Sema] Add -Wcast-function-type-strictSami Tolvanen1-20/+34
Clang supports indirect call Control-Flow Integrity (CFI) sanitizers (e.g. -fsanitize=cfi-icall), which enforce an exact type match between a function pointer and the target function. Unfortunately, Clang doesn't provide diagnostics that would help developers avoid function type casts that lead to runtime CFI failures. -Wcast-function-type, while helpful, only warns about ABI incompatibility, which isn't sufficient with CFI. Add -Wcast-function-type-strict, which checks for a strict type compatibility in function type casts and helps warn about casts that can potentially lead to CFI failures. Reviewed By: nickdesaulniers, aaron.ballman Differential Revision: https://reviews.llvm.org/D134831
2022-10-14[C2x] Implement support for nullptr and nullptr_tAaron Ballman1-0/+31
This introduces support for nullptr and nullptr_t in C2x mode. The proposal accepted by WG14 is: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3042.htm Note, there are quite a few incompatibilities with the C++ feature in some of the edge cases of this feature. Therefore, there are some FIXME comments in tests for testing behavior that might change after WG14 has resolved national body comments (a process we've not yet started). So this implementation might change slightly depending on the resolution of comments. This is called out explicitly in the release notes as well. Differential Revision: https://reviews.llvm.org/D135099
2022-04-09[randstruct] Add randomize structure layout supportConnor Kuehl1-0/+17
The Randstruct feature is a compile-time hardening technique that randomizes the field layout for designated structures of a code base. Admittedly, this is mostly useful for closed-source releases of code, since the randomization seed would need to be available for public and open source applications. Why implement it? This patch set enhances Clang’s feature parity with that of GCC which already has the Randstruct feature. It's used by the Linux kernel in certain structures to help thwart attacks that depend on structure layouts in memory. This patch set is a from-scratch reimplementation of the Randstruct feature that was originally ported to GCC. The patches for the GCC implementation can be found here: https://www.openwall.com/lists/kernel-hardening/2017/04/06/14 Link: https://lists.llvm.org/pipermail/cfe-dev/2019-March/061607.html Co-authored-by: Cole Nixon <nixontcole@gmail.com> Co-authored-by: Connor Kuehl <cipkuehl@gmail.com> Co-authored-by: James Foster <jafosterja@gmail.com> Co-authored-by: Jeff Takahashi <jeffrey.takahashi@gmail.com> Co-authored-by: Jordan Cantrell <jordan.cantrell@mail.com> Co-authored-by: Nikk Forbus <nicholas.forbus@gmail.com> Co-authored-by: Tim Pugh <nwtpugh@gmail.com> Co-authored-by: Bill Wendling <isanbard@gmail.com> Signed-off-by: Bill Wendling <isanbard@gmail.com> Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D121556
2022-04-08Revert D121556 "[randstruct] Add randomize structure layout support"Fangrui Song1-17/+0
This reverts commit 3f0587d0c668202bb89d29a25432aa290e551a31. Not all tests pass after a few rounds of fixes. I spot one failure that std::shuffle (potentially different results with different STL implementations) was misused and replaced it with llvm::shuffle, but there appears to be another failure in a Windows build. The latest failure is reported on https://reviews.llvm.org/D121556#3440383
2022-04-08[randstruct] Add randomize structure layout supportConnor Kuehl1-0/+17
The Randstruct feature is a compile-time hardening technique that randomizes the field layout for designated structures of a code base. Admittedly, this is mostly useful for closed-source releases of code, since the randomization seed would need to be available for public and open source applications. Why implement it? This patch set enhances Clang’s feature parity with that of GCC which already has the Randstruct feature. It's used by the Linux kernel in certain structures to help thwart attacks that depend on structure layouts in memory. This patch set is a from-scratch reimplementation of the Randstruct feature that was originally ported to GCC. The patches for the GCC implementation can be found here: https://www.openwall.com/lists/kernel-hardening/2017/04/06/14 Link: https://lists.llvm.org/pipermail/cfe-dev/2019-March/061607.html Co-authored-by: Cole Nixon <nixontcole@gmail.com> Co-authored-by: Connor Kuehl <cipkuehl@gmail.com> Co-authored-by: James Foster <jafosterja@gmail.com> Co-authored-by: Jeff Takahashi <jeffrey.takahashi@gmail.com> Co-authored-by: Jordan Cantrell <jordan.cantrell@mail.com> Co-authored-by: Nikk Forbus <nicholas.forbus@gmail.com> Co-authored-by: Tim Pugh <nwtpugh@gmail.com> Co-authored-by: Bill Wendling <isanbard@gmail.com> Signed-off-by: Bill Wendling <isanbard@gmail.com> Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D121556
2022-02-12[clang][sema] TryStaticCast - use castAs<> instead of getAs<> to avoid ↵Simon Pilgrim1-1/+1
dereference of nullptr The pointer is referenced immediately, so assert the cast is correct instead of returning nullptr
2022-02-07[SYCL] Disallow explicit casts between mismatching address spacesMariya Podchishchaeva1-1/+1
Reviewed By: bader Differential Revision: https://reviews.llvm.org/D118935
2021-10-12[clang] p0388 conversion to incomplete arrayNathan Sidwell1-1/+3
This implements the new implicit conversion sequence to an incomplete (unbounded) array type. It is mostly Richard Smith's work, updated to trunk, testcases added and a few bugs fixed found in such testing. It is not a complete implementation of p0388. Differential Revision: https://reviews.llvm.org/D102645
2021-07-30[PowerPC] Emit error for Altivec vector initializations when ↵Amy Kwan1-1/+24
-faltivec-src-compat=gcc is specified Under the -faltivec-src-compat=gcc option, AltiVec vector initialization should be treated as if they were compiled with gcc - which is, to emit an error when the vectors are initialized in the parenthesized or non-parenthesized manner. This patch implements this behaviour. Differential Revision: https://reviews.llvm.org/D106410
2021-07-19[PowerPC] Implement vector bool/pixel initialization under ↵Amy Kwan1-5/+18
-faltivec-src-compat=xl This patch implements the initialization of vectors under the -faltivec-src-compat=xl option introduced in https://reviews.llvm.org/D103615. Under this option, the initialization of scalar vectors, vector bool, and vector pixel are treated the same, where the initialization value is splatted across the whole vector. This patch does not change the behaviour of the -faltivec-src-compat=mixed option, which is the current default for Clang. Differential Revision: https://reviews.llvm.org/D106120
2021-07-05[C++][Sema] Ignore top-level qualifiers in castsOle Strohm1-0/+9
Ignore top-level qualifiers in casts, which fixes issues in reinterpret_cast. This rule comes from [expr.type]/8.2.2 which explains that casting to a pr-qualified type should actually cast to the unqualified type. In C++ this is only done for types that aren't classes or arrays. Fixes: PR49221 Reviewed By: Anastasia Differential Revision: https://reviews.llvm.org/D102689
2021-06-11[ADT] Remove APInt/APSInt toString() std::string variantsSimon Pilgrim1-1/+1
<string> is currently the highest impact header in a clang+llvm build: https://commondatastorage.googleapis.com/chromium-browser-clang/llvm-include-analysis.html One of the most common places this is being included is the APInt.h header, which needs it for an old toString() implementation that returns std::string - an inefficient method compared to the SmallString versions that it actually wraps. This patch replaces these APInt/APSInt methods with a pair of llvm::toString() helpers inside StringExtras.h, adjusts users accordingly and removes the <string> from APInt.h - I was hoping that more of these users could be converted to use the SmallString methods, but it appears that most end up creating a std::string anyhow. I avoided trying to use the raw_ostream << operators as well as I didn't want to lose having the integer radix explicit in the code. Differential Revision: https://reviews.llvm.org/D103888
2021-06-09[clang] NFC: Rename rvalue to prvalueMatheus Izvekov1-9/+10
This renames the expression value categories from rvalue to prvalue, keeping nomenclature consistent with C++11 onwards. C++ has the most complicated taxonomy here, and every other language only uses a subset of it, so it's less confusing to use the C++ names consistently, and mentally remap to the C names when working on that context (prvalue -> rvalue, no xvalues, etc). Renames: * VK_RValue -> VK_PRValue * Expr::isRValue -> Expr::isPRValue * SK_QualificationConversionRValue -> SK_QualificationConversionPRValue * JSON AST Dumper Expression nodes value category: "rvalue" -> "prvalue" Signed-off-by: Matheus Izvekov <mizvekov@gmail.com> Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D103720
2021-05-28[Matrix] Move C++ matrix cast checks to TryStaticCast.Florian Hahn1-14/+8
At the moment, the matrix support in CheckCXXCStyleCast (added in D101696) breaks function-style constructor calls that take a single matrix value, because it is treated as matrix cast. Instead, unify the C++ matrix cast handling by moving the logic to TryStaticCast and only handle the case where both types are matrix types. Otherwise, fall back to the generic mis-match detection. Suggested by @rjmccall Reviewed By: SaurabhJha Differential Revision: https://reviews.llvm.org/D103163
2021-05-17[OpenCL] Fix reinterpret_cast of vectorsOle Strohm1-0/+10
Fixes issues with vectors in reinterpret_cast in C++ for OpenCL and adds tests to make sure they both pass without errors and generate the correct code. Fixes: PR47977 Reviewed By: Anastasia Differential Revision: https://reviews.llvm.org/D101519
2021-05-16[Matrix] Implement static cast for matrix typesSaurabh Jha1-0/+7
This patch implements static casts for matrix types. This patch finishes all the work needed for https://bugs.llvm.org/show_bug.cgi?id=47141 Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D102125
2021-05-04[Matrix] Implement C-style explicit type conversions in CXX for matrix typesSaurabh Jha1-0/+7
This patch implements C-style explicit type conversions in CXX for matrix types. It is part of fixing https://bugs.llvm.org/show_bug.cgi?id=47141 Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D101696
2021-04-10[Matrix] Implement C-style explicit type conversions for matrix types.Saurabh Jha1-4/+12
This implements C-style type conversions for matrix types, as specified in clang/docs/MatrixTypes.rst. Fixes PR47141. Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D99037
2021-03-24[Clang][Sema] Implement GCC -Wcast-function-typeYuanfang Chen1-1/+99
``` Warn when a function pointer is cast to an incompatible function pointer. In a cast involving function types with a variable argument list only the types of initial arguments that are provided are considered. Any parameter of pointer-type matches any other pointer-type. Any benign differences in integral types are ignored, like int vs. long on ILP32 targets. Likewise type qualifiers are ignored. The function type void (*) (void) is special and matches everything, which can be used to suppress this warning. In a cast involving pointer to member types this warning warns whenever the type cast is changing the pointer to member type. This warning is enabled by -Wextra. ``` Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D97831
2021-03-12[OpenCL] Refactor diagnostic for OpenCL extension/featureAnton Zabaznov1-2/+2
There is no need to check for enabled pragma for core or optional core features, thus this check is removed Reviewed By: Anastasia Differential Revision: https://reviews.llvm.org/D97058
2020-11-19[AArch64][SVE] Allow C-style casts between fixed-size and scalable vectorsJoe Ellis1-0/+13
This patch allows C-style casting between fixed-size and scalable vectors. This kind of cast was previously blocked by the compiler, but it should be allowed. Differential Revision: https://reviews.llvm.org/D91262
2020-10-08[AST][RecoveryExpr] Support dependent cast-expr in C for error-recovery.Haojian Wu1-0/+11
Suppress spurious "typecheck_cond_expect_scalar_operand" diagnostic. See whole context: https://reviews.llvm.org/D85025 Reviewed By: sammccall Differential Revision: https://reviews.llvm.org/D84387
2020-09-16[Sema][MSVC] warn at dynamic_cast/typeid when /GR- is givenZequan Wu1-0/+12
Differential Revision: https://reviews.llvm.org/D86369
2020-09-14[AST][FPEnv] Keep FP options in trailing storage of CastExprSerge Pavlov1-15/+14
This is recommit of 6c8041aa0f, reverted in de044f7562 because of some fails. Original commit message is below. This change allow a CastExpr to have optional FPOptionsOverride object, stored in trailing storage. Of all cast nodes only ImplicitCastExpr, CStyleCastExpr, CXXFunctionalCastExpr and CXXStaticCastExpr are allowed to have FPOptions. Differential Revision: https://reviews.llvm.org/D85960
2020-09-12Revert "[AST][FPEnv] Keep FP options in trailing storage of CastExpr"Serge Pavlov1-13/+15
This reverts commit 6c8041aa0ffed827636935e59c489b1e390c8542. It caused some fails on buildbots.
2020-09-12[AST][FPEnv] Keep FP options in trailing storage of CastExprSerge Pavlov1-15/+13
This change allow a CastExpr to have optional FPOptionsOverride object, stored in trailing storage. Of all cast nodes only ImplicitCastExpr, CStyleCastExpr, CXXFunctionalCastExpr and CXXStaticCastExpr are allowed to have FPOptions. Differential Revision: https://reviews.llvm.org/D85960
2020-09-08Revert 3e782bf809 "[Sema][MSVC] warn at dynamic_cast when /GR- is given"Hans Wennborg1-12/+0
This caused more warnings than expected, see https://crbug.com/1126019 Also reverts the follow-up 7907e5516. > Differential Revision: https://reviews.llvm.org/D86369
2020-09-07[Sema][MSVC] warn at dynamic_cast when /GR- is givenZequan Wu1-0/+12
Differential Revision: https://reviews.llvm.org/D86369
2020-08-16[Sema] Use the proper cast for a fixed bool enum.Mark de Wever1-1/+7
When casting an enumerate with a fixed bool type the casting should use an IntegralToBoolean instead of an IntegralCast as is required per Core Issue 2338. Fixes PR47055: Incorrect codegen for enum with bool underlying type Differential Revision: https://reviews.llvm.org/D85612
2020-08-07[Sema] Add casting check for fixed to fixed point conversionsVince Bridgers1-0/+2
This change squelches the warning for a cast from fixed to fixed point conversions when -Wbad-function-cast is enabled. Fixes: cast from function call of type '_Fract' to non-matching type '_Fract' [-Wbad-function-cast] Reviewed By: bjope Differential Revision: https://reviews.llvm.org/D85157
2020-07-28[clang] Pass the NamedDecl* instead of the DeclarationName into many ↵Bruno Ricci1-4/+2
diagnostics. Background: ----------- There are two related argument types which can be sent into a diagnostic to display the name of an entity: DeclarationName (ak_declarationname) or NamedDecl* (ak_nameddecl) (there is also ak_identifierinfo for IdentifierInfo*, but we are not concerned with it here). A DeclarationName in a diagnostic will just be streamed to the output, which will directly result in a call to DeclarationName::print. A NamedDecl* in a diagnostic will also ultimately result in a call to DeclarationName::print, but with two customisation points along the way: The first customisation point is NamedDecl::getNameForDiagnostic which is overloaded by FunctionDecl, ClassTemplateSpecializationDecl and VarTemplateSpecializationDecl to print the template arguments, if any. The second customisation point is NamedDecl::printName. By default it just streams the stored DeclarationName into the output but it can be customised to provide a user-friendly name for an entity. It is currently overloaded by DecompositionDecl and MSGuidDecl. What this patch does: --------------------- For many diagnostics a DeclarationName is used instead of the NamedDecl*. This bypasses the two customisation points mentioned above. This patches fix this for diagnostics in Sema.cpp, SemaCast.cpp, SemaChecking.cpp, SemaDecl.cpp, SemaDeclAttr.cpp, SemaDecl.cpp, SemaOverload.cpp and SemaStmt.cpp. I have only modified diagnostics where I could construct a test-case which demonstrates that the change is appropriate (either with this patch or the next one). Reviewed By: erichkeane, aaron.ballman Differential Revision: https://reviews.llvm.org/D84656
2020-06-10[clang][Attribute] Fix noderef attribute false-negativesLeonard Chan1-0/+30
`noderef` was failing to trigger warnings in some cases related to c++ style casting. This patch addresses them. Differential Revision: https://reviews.llvm.org/D77836
2020-06-05[ARM] Add __bf16 as new Bfloat16 C TypeTies Stuij1-0/+14
Summary: This patch upstreams support for a new storage only bfloat16 C type. This type is used to implement primitive support for bfloat16 data, in line with the Bfloat16 extension of the Armv8.6-a architecture, as detailed here: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a The bfloat type, and its properties are specified in the Arm Architecture Reference Manual: https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile In detail this patch: - introduces an opaque, storage-only C-type __bf16, which introduces a new bfloat IR type. This is part of a patch series, starting with command-line and Bfloat16 assembly support. The subsequent patches will upstream intrinsics support for BFloat16, followed by Matrix Multiplication and the remaining Virtualization features of the armv8.6-a architecture. The following people contributed to this patch: - Luke Cheeseman - Momchil Velikov - Alexandros Lamprineas - Luke Geeson - Simon Tatham - Ties Stuij Reviewers: SjoerdMeijer, rjmccall, rsmith, liutianle, RKSimon, craig.topper, jfb, LukeGeeson, fpetrogalli Reviewed By: SjoerdMeijer Subscribers: labrinea, majnemer, asmith, dexonsmith, kristof.beyls, arphaman, danielkiss, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D76077
2020-06-01[Matrix] Implement matrix index expressions ([][]).Florian Hahn1-0/+3
This patch implements matrix index expressions (matrix[RowIdx][ColumnIdx]). It does so by introducing a new MatrixSubscriptExpr(Base, RowIdx, ColumnIdx). MatrixSubscriptExprs are built in 2 steps in ActOnMatrixSubscriptExpr. First, if the base of a subscript is of matrix type, we create a incomplete MatrixSubscriptExpr(base, idx, nullptr). Second, if the base is an incomplete MatrixSubscriptExpr, we create a complete MatrixSubscriptExpr(base->getBase(), base->getRowIdx(), idx) Similar to vector elements, it is not possible to take the address of a MatrixSubscriptExpr. For CodeGen, a new MatrixElt type is added to LValue, which is very similar to VectorElt. The only difference is that we may need to cast the type of the base from an array to a vector type when accessing it. Reviewers: rjmccall, anemet, Bigcheese, rsmith, martong Reviewed By: rjmccall Differential Revision: https://reviews.llvm.org/D76791
2020-05-22[SYCL] Prohibit arithmetic operations for incompatible pointersAlexey Bader1-4/+4
Summary: This change enables OpenCL diagnostics for the pointers annotated with address space attribute SYCL mode. Move `isAddressSpaceOverlapping` method from PointerType to QualType. Reviewers: Anastasia, rjmccall Reviewed By: rjmccall Subscribers: rjmccall, jeroen.dobbelaere, Fznamznon, yaxunl, ebevhan, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D80317
2020-05-18[OpenCL] Added addrspace_cast operator in C++ mode.Anastasia Stulova1-18/+50
This operator is intended for casting between pointers to objects in different address spaces and follows similar logic as const_cast in C++. Tags: #clang Differential Revision: https://reviews.llvm.org/D60193
2020-03-25[Sema][SVE] Allow casting SVE types to themselves in CRichard Sandiford1-0/+7
Casts from an SVE type to itself aren't very useful, but they are supposed to be valid, and could occur in things like macro expansions. Such casts already work for C++ and are tested by sizeless-1.cpp. This patch makes them work for C too. Differential Revision: https://reviews.llvm.org/D76694
2020-03-09Don't emit pointer to int cast warnings under -Wmicrosoft-castArthur Eubanks1-3/+1
Summary: MSVC also warns on this: $ cat /tmp/a.c int f(void* p) { return (int) p; } $ cl /c /tmp/a.c C:/src/tmp/a.c(1): warning C4311: 'type cast': pointer truncation from 'void *' to 'int' Warnings originally added in https://reviews.llvm.org/D72231. Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D75643
2020-03-07[Sema] Add -Wpointer-to-enum-cast and -Wvoid-pointer-to-enum-castNathan Chancellor1-5/+10
GCC does not warn on casts from pointers to enumerators, while clang currently does: https://godbolt.org/z/3DFDVG This causes a bunch of extra warnings in the Linux kernel, where certain structs contain a void pointer to avoid using a gigantic union for all of the various types of driver data, such as versions. Add a diagnostic that allows certain projects like the kernel to disable the warning just for enums, which allows those projects to keep full compatibility with GCC but keeps the intention of treating casts to integers and enumerators the same by default so that other projects have the opportunity to catch issues not noticed before (or follow suite and disable the warning). Link: https://github.com/ClangBuiltLinux/linux/issues/887 Reviewed By: rjmccall Differential Revision: https://reviews.llvm.org/D75758
2020-03-05Add warnings for casting ptr -> smaller int for C++ in Microsoft modeArthur Eubanks1-6/+12
Adds warnings to groups recently added in https://reviews.llvm.org/D72231. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D75708
2020-02-22[Sema] Fix pointer-to-int-cast diagnostic for _BoolMark de Wever1-1/+2
The diagnostic added in D72231 also shows a diagnostic when casting to a _Bool. This is unwanted. This patch removes the diagnostic for _Bool types. Differential Revision: https://reviews.llvm.org/D74860
2020-02-16[Sema] Adds the pointer-to-int-cast diagnosticMark de Wever1-6/+20
Converting a pointer to an integer whose result cannot represented in the integer type is undefined behavior is C and prohibited in C++. C++ already has a diagnostic when casting. This adds a diagnostic for C. Since this diagnostic uses the range of the conversion it also modifies int-to-pointer-cast diagnostic to use a range. Fixes PR8718: No warning on casting between pointer and non-pointer-sized int Differential Revision: https://reviews.llvm.org/D72231
2020-02-07[OpenCL] Restrict addr space conversions in nested pointersAnastasia Stulova1-0/+18
Address space conversion changes pointer representation. This commit disallows such conversions when they are not legal i.e. for the nested pointers even with compatible address spaces. Because the address space conversion in the nested levels can't be generated to modify the pointers correctly. The behavior implemented is as follows: - Any implicit conversions of nested pointers with different address spaces is rejected. - Any conversion of address spaces in nested pointers in safe casts (e.g. const_cast or static_cast) is rejected. - Conversion in low level C-style or reinterpret_cast is accepted but with a warning (this aligns with OpenCL C behavior). Fixes PR39674 Differential Revision: https://reviews.llvm.org/D73360
2020-01-09[Concepts] Function trailing requires clausesSaar Raz1-1/+1
Function trailing requires clauses now parsed, supported in overload resolution and when calling, referencing and taking the address of functions or function templates. Differential Revision: https://reviews.llvm.org/D43357
2019-12-18Refactor CompareReferenceRelationship and its callers in preparation forRichard Smith1-7/+3
implementing the resolution of CWG2352. No functionality change, except that we now convert the referent of a reference binding to the underlying type of the reference in more cases; we used to happen to preserve the type sugar from the referent if the only type change was in the cv-qualifiers. This exposed a bug in how we generate code for trivial assignment operators: if the type sugar (particularly the may_alias attribute) got lost during reference binding, we'd use the "wrong" TBAA information for the load during the assignment.
2019-12-16Check whether the destination is a complete type in a static_cast (orRichard Smith1-3/+8
C-style cast) to an enumeration type. We previously forgot to check this, and happened to get away with it (with bad diagnostics) only because we misclassified incomplete enumeration types as not being unscoped enumeration types. This also fixes the misclassification.
2019-11-04[Diagnostics] Improve some error messages related to bad use of dynamic_castDávid Bolvanský1-1/+1
generated by cgit v1.1 at 2025-10-12 09:04:46 +0000