## Purpose
Reverts the preprocessor guards added to the `dump()` methods in
`llvm/Support/ScaledNumber.h` in #139938 so that the header can be
included when building an external project in debug mode against a
release LLVM build.
## Overview
This is a clean revert of two files modified in #139938. The rest of
that change should not cause similar problems.
## Background
The following new build error was reported on #139938, which was merged
last week:
```
module.cpp:(.text._ZNK4llvm12ScaledNumberImE4dumpEv[_ZNK4llvm12ScaledNumberImE4dumpEv]+0x34): undefined reference to `llvm::ScaledNumberBase::dump(unsigned long, short, int)'
```
See further discussion on #139938.
## Validation
Implemented a simple external LLVM project to reproduce the issue.
Verified the the following link failure is observed on LLVM main
(Windows + Clang) without this change:
```
C:\WINDOWS\system32\cmd.exe /C "cd . && C:\PROGRA~1\LLVM\bin\CLANG_~1.EXE -nostartfiles -nostdlib -O0 -g -Xclang -gcodeview -D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd -Xlinker /subsystem:console -fuse-ld=lld-link CMakeFiles/llvm-dump-test.dir/main.cxx.obj -o llvm-dump-test.exe -Xlinker /MANIFEST:EMBED -Xlinker /implib:llvm-dump-test.lib -Xlinker /pdb:llvm-dump-test.pdb -Xlinker /version:0.0 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 -loldnames && cd ."
lld-link: error: undefined symbol: public: static void __cdecl llvm::ScaledNumberBase::dump(unsigned __int64, short, int)
>>> referenced by S:\llvm\llvm-project\llvm\include\llvm\Support\ScaledNumber.h:614
>>> CMakeFiles/llvm-dump-test.dir/main.cxx.obj:(public: void __cdecl llvm::ScaledNumber<unsigned __int64>::dump(void) const)
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
```
Verified the link issue is resolved after applying this change.
Also, manually included all header files that were modified in #139938
in the test program and verified there are no other link errors.
## Purpose
Add proper preprocessor guards for all `dump()` methods in the LLVM
support library. This change ensures these methods are not part of the
public ABI for release builds.
## Overview
* Annotates all `dump` methods in Support and ADT source with the
`LLVM_DUMP_METHOD` macro.
* Conditionally includes all `dump` method definitions in Support and
ADT source so they are only present on debug/assert builds and when
`LLVM_ENABLE_DUMP` is explicitly defined.
NOTE: For many of these `dump` methods, the implementation was already
properly guarded but the declaration in the header file was not.
## Background
This PR is a redo of #139804 with some changes to fix clang and unit
test build breaks.
This issue was raised in comments on #136629. I am addressing it as a
separate change since it is independent from the changes being made in
that PR.
According to [this
documentation](https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/Support/Compiler.h#L637),
`dump` methods should be annotated with `LLVM_DUMP_METHOD` and
conditionally included as follows:
```
#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
LLVM_DUMP_METHOD void dump() const;
#endif
```
## Validation
* Local release build succeeds.
* CI
## Purpose
Add proper preprocessor guards for all `dump()` methods in the LLVM
support library. This change ensures these methods are not part of the
public ABI for release builds.
## Overview
* Annotates all `dump` methods in Support and ADT source with the
`LLVM_DUMP_METHOD` macro.
* Conditionally includes all `dump` method definitions in Support and
ADT source so they are only present on debug/assert builds and when
`LLVM_ENABLE_DUMP` is explicitly defined.
NOTE: For many of these `dump` methods, the implementation was already
properly guarded but the declaration in the header file was not.
## Background
This issue was raised in comments on #136629. I am addressing it as a
separate change since it is independent from the changes being made in
that PR.
According to [this
documentation](https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/Support/Compiler.h#L637),
`dump` methods should be annotated with `LLVM_DUMP_METHOD` and
conditionally included as follows:
```
#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
LLVM_DUMP_METHOD void dump() const;
#endif
```
## Validation
* Local release build succeeds.
* CI
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
At least the plugin used by the LibreOffice build
(<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly
uses those members (through inline functions in LLVM/Clang include files in turn
using them), but they are not exported by utils/extract_symbols.py on Windows,
and accessing data across DLL/EXE boundaries on Windows is generally
problematic.
Differential Revision: https://reviews.llvm.org/D26671
llvm-svn: 289647
utils/sort_includes.py.
I clearly haven't done this in a while, so more changed than usual. This
even uncovered a missing include from the InstrProf library that I've
added. No functionality changed here, just mechanical cleanup of the
include order.
llvm-svn: 225974
Clang's static analyzer found several potential cases of undefined
behavior, use of un-initialized values, and potentially null pointer
dereferences in tablegen, Support, MC, and ADT. This cleans them up
with specific assertions on the assumptions of the code.
llvm-svn: 224154
ScaledNumber has been cleaned up enough to pull out of BFI now. Still
work to do there (tests for shifting, bloated printing code, etc.), but
it seems clean enough for its new home.
llvm-svn: 211562
