The warning fires on non-suspicious code in Chromium. Reverting until a
solution is figured out.
> Recommit r308327 2nd time: Add a warning for missing
> '#pragma pack (pop)' and suspicious uses of '#pragma pack' in included files
>
> The first recommit (r308441) caused a "non-default #pragma pack value might
> change the alignment of struct or union members in the included file" warning
> in LLVM itself. This recommit tweaks the added warning to avoid warnings for
> #includes that don't have any records that are affected by the non-default
> alignment. This tweak avoids the previously emitted warning in LLVM.
>
> Original message:
>
> This commit adds a new -Wpragma-pack warning. It warns in the following cases:
>
> - When a translation unit is missing terminating #pragma pack (pop) directives.
> - When entering an included file if the current alignment value as determined
> by '#pragma pack' directives is different from the default alignment value.
> - When leaving an included file that changed the state of the current alignment
> value.
>
> rdar://10184173
>
> Differential Revision: https://reviews.llvm.org/D35484
llvm-svn: 309186
Summary:
`clang --autocomplete=-std` will show
```
-std: Language standard to compile for
-std= Language standard to compile for
-stdlib= C++ standard library to use
```
after this change.
However, showing HelpText with completion in bash seems super tricky, so
this feature will be used in other shells (fish, zsh...).
Reviewers: v.g.vassilev, teemperor, ruiu
Subscribers: cfe-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D35759
llvm-svn: 309113
Summary:
File path wasn't autocompleted after `-fmodule-cache-path=[tab]`, so
fixed this bug by checking if $flags contains only a newline or not.
Differential Revision: https://reviews.llvm.org/D35763
llvm-svn: 309112
'#pragma pack (pop)' and suspicious uses of '#pragma pack' in included files
The first recommit (r308441) caused a "non-default #pragma pack value might
change the alignment of struct or union members in the included file" warning
in LLVM itself. This recommit tweaks the added warning to avoid warnings for
#includes that don't have any records that are affected by the non-default
alignment. This tweak avoids the previously emitted warning in LLVM.
Original message:
This commit adds a new -Wpragma-pack warning. It warns in the following cases:
- When a translation unit is missing terminating #pragma pack (pop) directives.
- When entering an included file if the current alignment value as determined
by '#pragma pack' directives is different from the default alignment value.
- When leaving an included file that changed the state of the current alignment
value.
rdar://10184173
Differential Revision: https://reviews.llvm.org/D35484
llvm-svn: 309106
std::byte, when defined as an enum, needs to be given special treatment
with regards to its aliasing properties. An array of std::byte is
allowed to be used as storage for other types.
This fixes PR33916.
Differential Revision: https://reviews.llvm.org/D35824
llvm-svn: 309058
Summary: You can now use REQUIRES:abi-breaking-checks in clang too
Reviewers: chapuni, probinson, ddunbar, jroelofs
Reviewed By: jroelofs
Subscribers: jroelofs, cfe-commits
Differential Revision: https://reviews.llvm.org/D35426
llvm-svn: 309049
This patch adds functionality and a test for importing Objective-C classes
and their methods.
It also adds a flag to clang-import-test to set the language used for
parsing. This takes the same argument format as the -x option to the
driver.
Differential Revision: https://reviews.llvm.org/D35274
llvm-svn: 309014
The instrumentation generated by -fsanitize=vptr does not null check a
user pointer before loading from it. This causes crashes in the face of
UB member calls (this=nullptr), i.e it's causing user programs to crash
only after UBSan is turned on.
The fix is to make run-time null checking a prerequisite for enabling
-fsanitize=vptr, and to then teach UBSan to reuse these run-time null
checks to make -fsanitize=vptr safe.
Testing: check-clang, check-ubsan, a stage2 ubsan-enabled build
Differential Revision: https://reviews.llvm.org/D35735https://bugs.llvm.org/show_bug.cgi?id=33881
llvm-svn: 309007
This feature allows the analyzer to consider loops to completely unroll.
New requirements/rules (for unrolling) can be added easily via ASTMatchers.
Right now it is hidden behind a flag, the aim is to find the correct heuristic
and create a solution which results higher coverage % and more precise
analysis, thus can be enabled by default.
Right now the blocks which belong to an unrolled loop are marked by the
LoopVisitor which adds them to the ProgramState.
Then whenever we encounter a CFGBlock in the processCFGBlockEntrance which is
marked then we skip its investigating. That means, it won't be considered to
be visited more than the maximal bound for visiting since it won't be checked.
llvm-svn: 309006
Projects that want to statically link their own C++ standard library currently
need to pass -nostdlib or -nodefaultlibs, which also disables linking of the
builtins library, -lm, and so on. Alternatively, they could use `clang` instead
of `clang++`, but that already disables implicit addition of -lm on some
toolchains.
Add a dedicated flag -nostdlib++ that disables just linking of libc++ /
libstdc++. This is analogous to -nostdinc++.
https://reviews.llvm.org/D35780
llvm-svn: 308997
Add a 'Generalized' object kind to the retain-count checker and suitable
generic diagnostic text for retain-count diagnostics involving those objects.
For now the object kind is introduced in summaries by 'annotate' attributes.
Once we have more experience with these annotations we will propose explicit
attributes.
Patch by Malhar Thakkar!
Differential Revision: https://reviews.llvm.org/D35613
llvm-svn: 308990
Notifying the author via Diffusion did not yield any answer. Therefore, I'm
adding the missing triple. I have no idea if this is the intended triple, but
it seems to fit the bill and should turn the bots back to green.
If the intended triple is a different one, please feel free to change it but I
need make this change to turn the bots back to green now.
llvm-svn: 308985
CurrentDir was set as the path of the current module, but that can change as
part of a chain of loaded modules.
When we try to locate a file mentioned in a module that does not exist, we use
a heuristic to look at the relative path between the original location of the
module and the file we look for, and use that relatively to the CurrentDir.
This only works if CurrentDir is the same as the (current) path of the module
file the file was mentioned in; if it is not, we look at the path relatively to
the wrong directory, and can end up reading random unrelated files that happen
to have the same name.
This patch fixes this by using the BaseDirectory of the module file the file
we look for was mentioned in instead of the CurrentDir heuristic.
Differential Revision: https://reviews.llvm.org/D35828
llvm-svn: 308962
Because since r308957 the suppress-on-sink feature contains its own
mini-analysis, it also needs to become aware that C++ unhandled exceptions
cause sinks. Unfortunately, for now we treat all exceptions as unhandled in
the analyzer, so suppress-on-sink needs to do the same.
rdar://problem/28157554
Differential Revision: https://reviews.llvm.org/D35674
llvm-svn: 308961
If a certain memory leak (or other similar bug) found by the analyzer is known
to be happening only before abnormal termination of the program ("sink", eg.
assertion failure in the code under analysis, or another bug that introduces
undefined behavior), such leak warning is discarded. However, if the analysis
has never reaches completion (due to complexity of the code), it may be
failing to notice the sink.
This commit further extends the partial solution introduced in r290341 to cover
cases when a complicated control flow occurs before encountering a no-return
statement (which anyway inevitably leads to such statement(s)) by traversing
the respective section of the CFG in a depth-first manner. A complete solution
still seems elusive.
rdar://problem/28157554
Differential Revision: https://reviews.llvm.org/D35673
llvm-svn: 308957
- This will also be used for the forthcoming __VA_OPT__ feature approved for C++2a.
- recommended by rsmith during his review of the __VA_OPT__ patch (https://reviews.llvm.org/D35782)
llvm-svn: 308948
This patch adds an early exit to CGDebugInfo::completeClassData() when
compiling with -gmodules and the to-be-completed type is available in
a clang module.
rdar://problem/23599990
llvm-svn: 308938
This reverts r308867 and r308866.
It broke the sanitizer-windows buildbot on C++ code similar to the
following:
namespace cl { }
void f() {
__asm {
mov al, cl
}
}
t.cpp(4,13): error: unexpected namespace name 'cl': expected expression
mov al, cl
^
In this case, MSVC parses 'cl' as a register, not a namespace.
llvm-svn: 308926
Under Windows Itanium, we need to export virtual and non-virtual thunks
if the functions being thunked are exported. These thunks would
previously inherit their dllexport attribute from the declaration, but
r298330 changed declarations to not have dllexport attributes. We
therefore need to add the dllexport attribute to the definition
ourselves now. This is consistent with MinGW GCC's behavior.
This redoes r306770 but limits the logic to Itanium. MicrosoftCXXABI's
setThunkLinkage ensures that thunks aren't exported under that ABI, so
I'm handling this in ItaniumCXXABI's setThunkLinkage for symmetry.
We need to export these thunks because they can be referenced outside
the library they're defined in. For example, if a child class without a
key function inherits from a parent class with a key function, the
parent's thunks will only be defined in the library with the key
function, but the construction vtable for the parent in the child might
be emitted outside the library (since the child doesn't have a key
function), and it needs to reference the parent's thunks.
We don't need to mark these thunks as imported since any references to
them will occur in data, so the compiler can't generate the IAT load
sequence anyway. Instead, we rely on the linker generating import thunks
for the thunks.
Differential Revision: https://reviews.llvm.org/D34972
llvm-svn: 308899
C2017 update 3 produces a clang that crashes when compiling clang. Disabling
optimizations for StmtProfiler::VisitCXXOperatorCallExpr() makes the crash go
away.
Patch from Bruce Dawson <brucedawson@chromium.org>!
https://reviews.llvm.org/D35757
llvm-svn: 308897
Summary:
This fixes a regression exposed by r307795 and rL308725 in which the level of a
comment line between '} else {' and a preprocessor directive is incorrectly set
as the level of the '} else {' line. For example, this :
```
int f(int i) {
if (i) {
++i;
} else {
// comment
#ifdef A
--i;
#endif
}
}
```
was formatted as:
```
int f(int i) {
if (i) {
++i;
} else {
// comment
#ifdef A
--i;
#endif
}
}
```
Reviewers: djasper, klimek
Reviewed By: klimek
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D35794
llvm-svn: 308882
Add support for -m(no-)extern-data when using -mgpopt in the driver. It is
enabled by default in the backend.
Reviewers: atanasyan, slthakur
Differential Revision: https://reviews.llvm.org/D35550
llvm-svn: 308879
On MS-style, the following snippet:
int eax;
__asm mov eax, ebx
should yield loading of ebx, into the location pointed by the variable eax
This patch sees to it.
Currently, a reg-to-reg move would have been invoked.
llvm: D34739
Differential Revision: https://reviews.llvm.org/D34740
llvm-svn: 308867
All but one place are checking options::OPT_nostdlib instead of looking at
this field, so convert that one other place to doing that as well.
No behavior change.
llvm-svn: 308848
This gets rid of almost LLVM targets unconditionally depending on intrinsic_gen.
Clang's modules still have weird dependencies and hard to remove intrinsics_gen in better way.
Then, it'd be better to give whole clang targets depend on intrinsic_gen.
llvm-svn: 308844
Konstantin Zhuravlyov