// Primary fixed point types
signed short _Accum s_short_accum;
signed _Accum s_accum;
signed long _Accum s_long_accum;
unsigned short _Accum u_short_accum;
unsigned _Accum u_accum;
unsigned long _Accum u_long_accum;
// Aliased fixed point types
short _Accum short_accum;
_Accum accum;
long _Accum long_accum;
This diff only allows for declaration of the fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. The saturated versions of these types and the equivalent _Fract types will also be added in future patches.
The tests included are for asserting that we can declare these types.
Fixed the test that was failing by not checking for dso_local on some
targets.
Differential Revision: https://reviews.llvm.org/D46084
llvm-svn: 333923
```
// Primary fixed point types
signed short _Accum s_short_accum;
signed _Accum s_accum;
signed long _Accum s_long_accum;
unsigned short _Accum u_short_accum;
unsigned _Accum u_accum;
unsigned long _Accum u_long_accum;
// Aliased fixed point types
short _Accum short_accum;
_Accum accum;
long _Accum long_accum;
```
This diff only allows for declaration of the fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. The saturated versions of these types and the equivalent `_Fract` types will also be added in future patches.
The tests included are for asserting that we can declare these types.
Differential Revision: https://reviews.llvm.org/D46084
llvm-svn: 333814
LLD also supports order files using the `--symbol-ordering-file` option.
As the name would suggest, the order file format is slightly different
from gold; gold's order files specify section names, whereas LLD's
specify symbol names. Assuming you have an order file in the correct
format though, we should support using it with LLD.
Switch the check to actually use LLVM's linker detection rather than
just checking for the presence of the gold executable, since we might
have a gold executable present but be using LLD (or bfd for that matter)
as our linker.
Differential Revision: https://reviews.llvm.org/D47669
llvm-svn: 333810
The idea is that a client that wants split dwarf would create a
specific kind of object writer that creates two files, and use it to
create the streamer.
Part of PR37466.
Differential Revision: https://reviews.llvm.org/D47050
llvm-svn: 332749
Second attempt. Fix line endings and warning.
As an addition to CXTranslationUnit_SkipFunctionBodies, provide the
new option CXTranslationUnit_LimitSkipFunctionBodiesToPreamble,
which constraints the skipping of functions bodies to the preamble
only. Function bodies in the main file are not affected if this
option is set.
Skipping function bodies only in the preamble is what clangd already
does and the introduced flag implements it for libclang clients.
Patch by Nikolai Kosjar.
Differential Revision: https://reviews.llvm.org/D45815
llvm-svn: 332587
As an addition to CXTranslationUnit_SkipFunctionBodies, provide the
new option CXTranslationUnit_LimitSkipFunctionBodiesToPreamble,
which constraints the skipping of functions bodies to the preamble
only. Function bodies in the main file are not affected if this
option is set.
Skipping function bodies only in the preamble is what clangd already
does and the introduced flag implements it for libclang clients.
Patch by Nikolai Kosjar.
Differential Revision: https://reviews.llvm.org/D45815
llvm-svn: 332578
Although not very well known, diagtool is an incredibly convenient
utility for dealing with diagnostics.
Particularly useful are the "tree" and "show-enabled" commands:
- The former prints the hierarchy of diagnostic (warning) flags and
which of them are enabled by default.
- The latter can be used to replace an invocation to clang and will
print which diagnostics are disabled, warnings or errors.
For instance: `diagtool show-enabled -Wall -Werror /tmp/test.c` will
print that -Wunused-variable (warn_unused_variable) will be treated as
an error.
This patch adds them to the install target so it gets shipped with the
LLVM release. It also adds a very basic man page and mentions this
change in the release notes.
Differential revision: https://reviews.llvm.org/D46694
llvm-svn: 332448
When bundle/unbundle intermediate files for HIP, there may be multiple
sub archs, therefore BoundArch needs to be included in the target
and output file names for clang-offload-bundler.
Differential Revision: https://reviews.llvm.org/D46473
llvm-svn: 332121
This commit relands r331904.
Adding a SrcMgr::CharacteristicKind parameter to the InclusionDirective
in PPCallbacks, and updating calls to that function. This will be useful
in https://reviews.llvm.org/D43778 to determine which includes are
system
headers.
Differential Revision: https://reviews.llvm.org/D46614
llvm-svn: 332021
Adding a SrcMgr::CharacteristicKind parameter to the InclusionDirective
in PPCallbacks, and updating calls to that function. This will be useful
in https://reviews.llvm.org/D43778 to determine which includes are system
headers.
Differential Revision: https://reviews.llvm.org/D46614
llvm-svn: 331904
This is similar to the LLVM change https://reviews.llvm.org/D46290.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46320
llvm-svn: 331834
libclang exposes the type of 'int (Foo);' (a global variable of type int
called Foo) as CXType_Unexposed. This is because Clang represents Foo's
type as ParenType{BuiltinType{Int}}, and libclang does not handle
ParenType.
Make libclang return CXType_Int as the type of 'int (Foo);' by
unwrapping ParenType transparently.
Patch by Matt Glazar.
Differential Revision: https://reviews.llvm.org/D45713
llvm-svn: 331306
Teach AsmParser to check with Assembler for when evaluating constant
expressions. This improves the handing of preprocessor expressions
that must be resolved at parse time. This idiom can be found as
assembling-time assertion checks in source-level assemblers. Note that
this relies on the MCStreamer to keep sufficient tabs on Section /
Fragment information which the MCAsmStreamer does not. As a result the
textual output may fail where the equivalent object generation would
pass. This can most easily be resolved by folding the MCAsmStreamer
and MCObjectStreamer together which is planned for in a separate
patch.
Currently, this feature is only enabled for assembly input, keeping IR
compilation consistent between assembly and object generation.
Reviewers: echristo, rnk, probinson, espindola, peter.smith
Reviewed By: peter.smith
Subscribers: eraman, peter.smith, arichardson, jyknight, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D45164
llvm-svn: 331218
When a '>>' token is split into two '>' tokens (in C++11 onwards), or (as an
extension) when we do the same for other tokens starting with a '>', we can't
just use a location pointing to the first '>' as the location of the split
token, because that would result in our miscomputing the length and spelling
for the token. As a consequence, for example, a refactoring replacing 'A<X>'
with something else would sometimes replace one character too many, and
similarly diagnostics highlighting a template-id source range would highlight
one character too many.
Fix this by creating an expansion range covering the first character of the
'>>' token, whose spelling is '>'. For this to work, we generalize the
expansion range of a macro FileID to be either a token range (the common case)
or a character range (used in this new case).
llvm-svn: 331155
LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in
HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the
default macro instead of a reinvented one.
See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev.
No intended behavior change.
llvm-svn: 331069
This patch is a tweak of changyu's patch: https://reviews.llvm.org/D40381. It differs in that the recognition of the 'concept' token is moved into the machinery that recognizes declaration-specifiers - this allows us to leverage the attribute handling machinery more seamlessly.
See the test file to get a sense of the basic parsing that this patch supports.
There is much more work to be done before concepts are usable...
Thanks Changyu!
llvm-svn: 330794
/usr/local/bin/ld.lld: error: undefined symbol: llvm::createAggressiveInstCombinerPass()
>>> referenced by cc1_main.cpp
>>> tools/clang/tools/driver/CMakeFiles/clang.dir/cc1_main.cpp.o:(_GLOBAL__sub_I_cc1_main.cpp)
And so on
The bot coverage is clearly missing.
llvm-svn: 330694
All attributes have a source range associated with it. However, implicit
attributes are added by the compiler, and not added because the user
wrote something in the input. So no token type should be set to
CXCursor_*Attr.
The problem was visible when a class gets marked by e.g.
MSInheritanceAttr, which has the full CXXRecordDecl's range as its
own range. The effect of marking that range as CXCursor_UnexposedAttr
was that all cursors for the record decl, including all child decls,
would become CXCursor_UnexposedAttr.
llvm-svn: 330692
Summary:
The FileID/Offset conversion is lossy. The code takes the fileLoc, which loses
e.g. the spelling location in some macro cases.
Instead, pass the original SourceLocation which preserves all information, and
update consumers to match current behavior.
This allows us to fix two bugs in clangd that need the spelling location.
Reviewers: akyrtzi, arphaman
Subscribers: ilya-biryukov, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D45014
llvm-svn: 329570
They were failing on Windows because the output YAML didn't parse:
YAML:1:664: error: Unrecognized escape code!
{"toolchain":"D:\\buildslave\\clang-x64-ninja-win7\\stage1",
"libclang.operation":"complete", "libclang.opts":1, "args":["clang",
"-fno-spell-checking",
"D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\test\Index\create-libclang-completion-reproducer.c",
"-Xclang", "-detailed-preprocessing-record",
"-fallow-editor-placeholders"],
"invocation-args":["-code-completion-at=D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\test\Index\create-libclang-completion-reproducer.c:10:1"],
"unsaved_file_hashes":[{"name":"D:\\buildslave\\clang-x64-ninja-win7\\llvm\\tools\\clang\\test\\Index\\create-libclang-completion-reproducer.c",
"md5":"aee23773de90e665992b48209351d70e"}]}
This adds some more escaping to try to make it work.
llvm-svn: 329558
Summary:
clang_getFileName() may return a path relative to WorkingDir.
On Arch Linux, during clang_indexTranslationUnit(), clang_getFileName() on
CXIdxIncludedIncludedFileInfo::file may return
"/../lib64/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/string",
for `#include <string>`.
I presume WorkingDir is somehow changed to /usr/lib or /usr/include and
clang_getFileName() returns a path relative to WorkingDir.
clang_File_tryGetRealPathName() returns "/usr/include/c++/7.3.0/string"
which is more useful for the indexer in this case.
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42893
llvm-svn: 329515
-cc1gen-reproducer driver option
The recommit fixes:
- An MSAN failure (CCPrintOptions wasn't initialized in the Driver)
- Ensures that the strings in the libclang invocation files are escaped
Original message:
This commit is a follow up to the previous work that recorded Libclang invocations
into temporary files: r319702.
It adds a new -cc1 mode to clang: -cc1gen-reproducer. The goal of this mode is to generate
Clang reproducer files for Libclang tool invocation. The JSON format in the invocation
files is not really intended to be stable, so Libclang and Clang should be of the same version
when generating reproducers.
The new mode emits the information about the temporary files and Libclang-specific information
to stdout using JSON.
rdar://35322614
Differential Revision: https://reviews.llvm.org/D40983
llvm-svn: 329465
driver option
This commit is a follow up to the previous work that recorded Libclang invocations
into temporary files: r319702.
It adds a new -cc1 mode to clang: -cc1gen-reproducer. The goal of this mode is to generate
Clang reproducer files for Libclang tool invocation. The JSON format in the invocation
files is not really intended to be stable, so Libclang and Clang should be of the same version
when generating reproducers.
The new mode emits the information about the temporary files and Libclang-specific information
to stdout using JSON.
rdar://35322614
Differential Revision: https://reviews.llvm.org/D40983
llvm-svn: 329442
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:
archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
methode
nd
optin
ot
pres
statics
te
thru
Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)
Differential revision: https://reviews.llvm.org/D44188
llvm-svn: 329399
Summary:
`ASTPrinter` allows setting the ouput to any O-Stream, but that printer creates source-code-like syntax (and is also marked with a `FIXME`). The nice, colourful, mostly human-readable `ASTDumper` only works on the standard output, which is not feasible in case a user wants to see the AST of a file through a code navigation/comprehension tool.
This small addition of an overload solves generating a nice colourful AST block for the users of a tool I'm working on, [[ http://github.com/Ericsson/CodeCompass | CodeCompass ]], as opposed to having to duplicate the behaviour of definitions that only exist in the anonymous namespace of implementation TUs related to this module.
Reviewers: alexfh, klimek, rsmith
Reviewed By: alexfh
Subscribers: rnkovacs, dkrupp, gsd, xazax.hun, cfe-commits, #clang
Tags: #clang
Patch by Whisperity!
Differential Revision: https://reviews.llvm.org/D45096
llvm-svn: 329391
This reverts r328795 which introduced an issue with referencing __global__
function templates. More details in the original review D44747.
llvm-svn: 329099
This patch sets target specific calling convention for CUDA kernels in IR.
Patch by Greg Rodgers.
Revised and lit test added by Yaxun Liu.
Differential Revision: https://reviews.llvm.org/D44747
llvm-svn: 328795
r327219 added wrappers to std::sort which randomly shuffle the container before
sorting. This will help in uncovering non-determinism caused due to undefined
sorting order of objects having the same key.
To make use of that infrastructure we need to invoke llvm::sort instead of
std::sort.
llvm-svn: 328636
Leonard Chan