Age | Commit message (Collapse) | Author | Files | Lines |
|
getRecord() can return nullptr if any one of the fields does, in this
case because the array is too large for us to allocate.
|
|
It did almost nothing
|
|
CheckEnumValue was not handling PT_IntAP/PT_IntAPS.
|
|
implicit casts (#149972)
## Motivation
`-Wunreachable-code` missed—or in rare cases crashed on—tautological
comparisons such as
```cpp
x != 0 || x != 1.0 // always true
x == 0 && x == 1.0 // always false
```
when the *same* variable appears on both sides but one operand goes
through a floating‑rank promotion that is target‑dependent. On back‑ends
with **native half‑precision** (`_Float16` / `__fp16`) such as
AArch64 `+fullfp16`, no promotion occurs, so the cast stacks between the
two operands differ and the existing heuristic bails out.
## Technical description
* **Extends `Expr::isSameComparisonOperand()`** – the helper now ignores
parentheses **and value‑preserving implicit casts**
(`CK_LValueToRValue`, floating‑rank `CK_FloatingCast`) before comparing
the underlying operands. This prevents floating‑rank promotions and
lvalue‑to‑rvalue conversions from blocking the unreachable‑code
diagnostic on targets with native FP16.
*No change needed in `CheckIncorrectLogicOperator`; it simply benefits
from the improved helper.*
* **Regression test** – `warn-unreachable_crash.cpp` updated to cover
both the promoted case (x86‑64) and the native‑half case
(AArch64 `+fullfp16`).
* **Docs** – release‑note bullet added under *Bug Fixes in This
Version*.
@ziqingluo-90 @yronglin Could you please review promptly? (feel free to
also merge it on my behalf) Thanks!
Fixes #149967
Co-authored-by: Zeeshan Siddiqui <mzs@ntdev.microsoft.com>
|
|
This has been explicitly forbidden since C++11, but somehow the edge
case of converting a function pointer to void* using a cast like
`(void*)f` wasn't handled.
Fixes #150340 .
|
|
This follows from a conversation on #150592 where we decided to
split out this change and commit it separately.
The rationale is that FunctionDecl must be sufficiently parsed/created
in order to tell whether it is a streaming function.
|
|
Remove else after return and remove some unused includes.
|
|
They are only relevant for block pointers.
|
|
Implicitly declared types (like __NSConstantString_tag, etc) will be
declared with visibility attributes. This causes problems when merging
ASTs because we currently reject declaration merging for declarations
with attributes.
This relaxes that restriction somewhat; implicit declarations can now
have attributes when merging; we assume that if the compiler generated
it, it's fine.
|
|
This was written out of an abundance of caution because the changes were
being added to the release branch. Now we can be a little less cautious
and switch to using an assert. No behavioral changes are expected.
|
|
The structural equivalence checker was not paying attention to whether
enumerations had compatible fixed underlying types or not.
Fixes #150594
|
|
To initialize all elements of a primitive array at once. This saves us
from creating the InitMap just to destroy it again after all elements
have been initialized.
|
|
The Cygwin target is generally very similar to the MinGW target. The
default auto-import behavior, the default calling convention, the
`.dll.a` import library extension, the `__GXX_TYPEINFO_EQUALITY_INLINE`
pre-define by `g++`, and the long double configuration.
Co-authored-by: Mateusz Mikuła <oss@mateuszmikula.dev>
|
|
An enumeration is compatible with its underlying type, which means that
code like the following should be accepted:
struct A { int h; };
void func() {
extern struct A x;
enum E : int { e };
struct A { enum E h; };
extern struct A x;
}
because the structures are declared in different scopes, the two
declarations of 'x' are both compatible.
Note, the structural equivalence checker does not take scope into
account, but that is something the C standard requires. This means we
are accepting code we should be rejecting per the standard, like:
void func() {
struct A { int h; };
extern struct A x;
enum E : int { e };
struct A { enum E h; };
extern struct A x;
}
Because the structures are declared in the same scope, the type
compatibility rule require the structures to use the same types, not
merely compatible ones.
Fixes #149965
|
|
|
|
My solution was to copy-paste getUnusedResultAttr and
hasUnusedResultAttr from CallExpr into ObjCMessageExpr too.
Fixes #141504
|
|
Signed-off-by: Bogdan Vetrenko <b.vetrenko@yandex.ru>
|
|
(#150559)
…Type
PR #118288 fixed a re-entrancy issue with the usage of `FoldingSet` and
`AutoType`. The following test case (reduced with `creduce` by
@Fznamznon):
```
template <typename C, typename S1, int rbits>
typename C::A Bar(const S1& x, const C& c = C()) {
using T = typename C::A;
T result;
using PreC = typename C::template boop<T::p + rbits>;
using ExactC = typename C::template bap<PreC::p + 2>;
using D = typename ExactC::A;
return result;
}
```
shows a similar non-deterministic recursion with the use of `FoldingSet`
but with `DependentTemplateSepcializationType`. A nearly identical fix
is needed here too.
|
|
Reverts llvm/llvm-project#147959
|
|
report_fatal_error is not a good way to report diagnostics to the users, so this switches to using actual diagnostic reporting mechanisms instead.
Fixes #147187
|
|
Like in other places, ignore the reference type of the base. (It might
make sense to refactor this at some point.)
Fixes #150015.
|
|
The initializer itself might need the field to be active.
|
|
trivially-default-constructible union members (#149835)
See
https://github.com/llvm/llvm-project/commit/faee39baa87e43f4b746dd77e479268391163658
|
|
This is also what the current interpreter does.
|
|
The decl can be null and this used to crash.
|
|
We use this construct a lot. Use something similar to clang's
UnsignedOrNone.
This results in some slighy compile time improvements:
https://llvm-compile-time-tracker.com/compare.php?from=17a4b0399d161a3b89d8f0ce82add1638f23f5d4&to=a251d81ecd0ed45dd190462663155fdb303ef04d&stat=instructions:u
|
|
As a way of writing atIndex(I).deref<T>(), which creates an intermediate
Pointer, which in turn adds (and removes) that pointer from the pointer
list of the Block. This way we can avoid that.
|
|
Fixes #138475
|
|
|
|
In #143667, we made constant evaluation fail on `*null_ptr`, as this is
UB. However, `&(*(foo*)0)` seems to be a common pattern, which made
#143667 too disruptive.
So instead of failing the evaluation, we note the UB, which let clang
recovers when checking for constant initialization.
Fixes #149500
|
|
sugar types (#149613)
The checks for the 'z' and 't' format specifiers added in the original
PR #143653 had some issues and were overly strict, causing some build
failures and were consequently reverted at
https://github.com/llvm/llvm-project/commit/4c85bf2fe8042c855c9dd5be4b02191e9d071ffd.
In the latest commit
https://github.com/llvm/llvm-project/pull/149613/commits/27c58629ec76a703fde9c0b99b170573170b4a7a,
I relaxed the checks for the 'z' and 't' format specifiers, so warnings
are now only issued when they are used with mismatched types.
The original intent of these checks was to diagnose code that assumes
the underlying type of `size_t` is `unsigned` or `unsigned long`, for
example:
```c
printf("%zu", 1ul); // Not portable, but not an error when size_t is unsigned long
```
However, it produced a significant number of false positives. This was
partly because Clang does not treat the `typedef` `size_t` and
`__size_t` as having a common "sugar" type, and partly because a large
amount of existing code either assumes `unsigned` (or `unsigned long`)
is `size_t`, or they define the equivalent of size_t in their own way
(such as
sanitizer_internal_defs.h).https://github.com/llvm/llvm-project/blob/2e67dcfdcd023df2f06e0823eeea23990ce41534/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h#L203
|
|
(#149462)
…nevaluated
Fake a function call to the given function and evaluate the given
expression as if it was part of that function call.
Fixes #149383
|
|
For mutable and const fields, we have two bits in InlineDescriptor,
which both get inherited down the hierarchy. When a field is both const
and mutable, we CAN read from it if it is a mutable-in-const field, but
we _can't_ read from it if it is a const-in-mutable field. We need
another bit to distinguish the two cases.
|
|
|
|
|
|
sugar types instead of built-in types (#143653)"
This reverts commit c27e283cfbca2bd22f34592430e98ee76ed60ad8.
A builbot failure has been reported:
https://lab.llvm.org/buildbot/#/builders/186/builds/10819/steps/10/logs/stdio
I'm also getting a large number of warnings related to %zu and %zx.
|
|
types instead of built-in types (#143653)
Including the results of `sizeof`, `sizeof...`, `__datasizeof`,
`__alignof`, `_Alignof`, `alignof`, `_Countof`, `size_t` literals, and
signed `size_t` literals, the results of pointer-pointer subtraction and
checks for standard library functions (and their calls).
The goal is to enable clang and downstream tools such as clangd and
clang-tidy to provide more portable hints and diagnostics.
The previous discussion can be found at #136542.
This PR implements this feature by introducing a new subtype of `Type`
called `PredefinedSugarType`, which was considered appropriate in
discussions. I tried to keep `PredefinedSugarType` simple enough yet not
limited to `size_t` and `ptrdiff_t` so that it can be used for other
purposes. `PredefinedSugarType` wraps a canonical `Type` and provides a
name, conceptually similar to a compiler internal `TypedefType` but
without depending on a `TypedefDecl` or a source file.
Additionally, checks for the `z` and `t` format specifiers in format
strings for `scanf` and `printf` were added. It will precisely match
expressions using `typedef`s or built-in expressions.
The affected tests indicates that it works very well.
Several code require that `SizeType` is canonical, so I kept `SizeType`
to its canonical form.
The failed tests in CI are allowed to fail. See the
[comment](https://github.com/llvm/llvm-project/pull/135386#issuecomment-3049426611)
in another PR #135386.
|
|
Add `NamespaceBaseDecl` as common base class of `NamespaceDecl` and
`NamespaceAliasDecl`. This simplifies `NestedNameSpecifier` a bit.
Co-authored-by: Matheus Izvekov <mizvekov@gmail.com>
|
|
getFinallyStmt() already returns ObjCAtFinallyStmt *.
|
|
(#149227)
071765749a70b22fb62f2efc07a3f242ff5b4c52 improved constexpr-unknown
diagnostics, but potential constant expression checking broke in the
process: we produce diagnostics in more cases. Suppress the diagnostics
as appropriate.
This fix affects -Winvalid-constexpr and the enable_if attribute. (The
-Winvalid-constexpr diagnostic isn't really important right now, but it
will become important if we allow constexpr-unknown with pre-C++23
standards.)
Fixes #149041. Fixes #149188.
|
|
Per [decl.ref],
> Because a null pointer value or a pointer past the end of an object
does not point to an object, a reference in a well-defined program
cannot refer to such things.
Note this does not fixes the new bytecode interpreter.
Fixes #48665
|
|
We need to compare to the end() interator.
|
|
|
|
Only activate things if the syntactical structure suggests so. This adds
a bunch of new opcodes to control whether to activate in stores, etc.
Fixes #134789
|
|
ASTContext::getDefaultCallingConvention() was documented as returning
"the default calling convention for the current target", but did not do
this, and was never intended to do this, it has always been controlled
by command-line options to deviate from the target default.
This commit changes ASTContext::getDefaultCallingConvention() to reflect
the fact that it returns the context's default calling convention, not
the target's default calling convention. The IsBuiltin parameter, which
was used to return the target's default calling convention rather than
the context's, is removed in favor of
getTargetInfo().getDefaultCallingConv() which is more explicit of the
intent.
|
|
width (#148692)
This avoids crashing due to template-dependent bit widths
|
|
Remove the Native Client support now that it has finally reached end of life.
|
|
A constexpr-unknown reference can be equal to an arbitrary value, except
values allocated during constant evaluation. Fix the handling.
The standard is unclear exactly which pointer comparisons count as
"unknown" in this context; for example, in some cases we could use
alignment to prove two constexpr-unknown references are not equal. I
decided to ignore all the cases involving variables not allocated during
constant evaluation.
While looking at this, I also spotted that there might be issues with
lifetimes, but I didn't try to address it.
|
|
This PR introduces the use of pointer authentication to objective-c[++].
This includes:
* __ptrauth qualifier support for ivars
* protection of isa and super fields
* protection of SEL typed ivars
* protection of class_ro_t data
* protection of methodlist pointers and content
|
|
|