| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
This is a recommit of r312781; in some build configurations
variable names are omitted, so changed the new regression
test accordingly.
llvm-svn: 312794
|
| |
|
|
|
|
|
| |
The clang-with-lto-ubuntu bot didn't like the new regression
test, revert while I investigate the issue.
llvm-svn: 312784
|
| |
|
|
|
|
|
|
|
|
|
| |
This adds _Float16 as a source language type, which is a 16-bit floating point
type defined in C11 extension ISO/IEC TS 18661-3.
In follow up patches documentation and more tests will be added.
Differential Revision: https://reviews.llvm.org/D33719
llvm-svn: 312781
|
| |
|
|
| |
llvm-svn: 310805
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
not present.
C++14 added user-defined literal support for complex numbers so that you
can write something like "complex<double> val = 2i". However, there is
an existing GNU extension supporting this syntax and interpreting the
result as a _Complex type.
This changes parsing so that such literals are interpreted in terms of
C++14's operators if an overload is present but otherwise falls back to
the original GNU extension.
(We now have more robust diagnostics for implicit conversions so the
libc++ test that caused the original revert still passes).
llvm-svn: 310478
|
| |
|
|
|
|
|
| |
This reverts r310423. It was committed by mistake, I intended to commit the
improved diagnostics for implicit conversions instead.
llvm-svn: 310426
|
| |
|
|
| |
llvm-svn: 310423
|
| |
|
|
|
|
| |
formatted. NFC.
llvm-svn: 304642
|
| |
|
|
|
|
|
|
|
| |
not present."
This reverts commit r303697. It broke libc++ tests that were specifically
checking incompatibility in C++14 mode.
llvm-svn: 303813
|
| |
|
|
| |
llvm-svn: 303734
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
C++14 added user-defined literal support for complex numbers so that you can
write something like "complex<double> val = 2i". However, there is an existing
GNU extension supporting this syntax and interpreting the result as a _Complex
type.
This changes parsing so that such literals are interpreted in terms of C++14's
operators if an overload is present but otherwise falls back to the original
GNU extension.
llvm-svn: 303694
|
| |
|
|
|
|
|
| |
This implements the compiler side of p0403r0. This patch was reviewed as
https://reviews.llvm.org/D26829.
llvm-svn: 290744
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This lets people link against LLVM and their own version of the UTF
library.
I determined this only affects llvm, clang, lld, and lldb by running
$ git grep -wl 'UTF[0-9]\+\|\bConvertUTF\bisLegalUTF\|getNumBytesFor' | cut -f 1 -d '/' | sort | uniq
clang
lld
lldb
llvm
Tested with
ninja lldb
ninja check-clang check-llvm check-lld
(ninja check-lldb doesn't complete for me with or without this patch.)
Reviewers: rnk
Subscribers: klimek, beanz, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D24996
llvm-svn: 282822
|
| |
|
|
|
|
|
|
| |
other minor fixes.
Differential revision: https://reviews.llvm.org/D24115
llvm-svn: 280870
|
| |
|
|
|
|
|
|
|
|
| |
Summary: Removed unused headers, replaced some headers with forward class declarations
Patch by: Eugene <claprix@yandex.ru>
Differential Revision: https://reviews.llvm.org/D20100
llvm-svn: 275882
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch corresponds to reviews:
http://reviews.llvm.org/D15120
http://reviews.llvm.org/D19125
It adds support for the __float128 keyword, literals and target feature to
enable it. Based on the latter of the two aforementioned reviews, this feature
is enabled on Linux on i386/X86 as well as SystemZ.
This is also the second attempt in commiting this feature. The first attempt
did not enable it on required platforms which caused failures when compiling
type_traits with -std=gnu++11.
If you see failures with compiling this header on your platform after this
commit, it is likely that your platform needs to have this feature enabled.
llvm-svn: 268898
|
| |
|
|
|
|
|
|
|
|
| |
Since this patch provided support for the __float128 type but disabled it
on all platforms by default, some platforms can't compile type_traits with
-std=gnu++11 since there is a specialization with __float128.
This reverts the patch until D19125 is approved (i.e. we know which platforms
need this support enabled).
llvm-svn: 266460
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch corresponds to review:
http://reviews.llvm.org/D15120
It adds support for the __float128 keyword, literals and a target feature to
enable it. This support is disabled by default on all targets and any target
that has support for this type is free to add it.
Based on feedback that I've received from target maintainers, this appears to
be the right thing for most targets. I have not heard from the maintainers of
X86 which I believe supports this type. I will subsequently investigate the
impact of enabling this on X86.
llvm-svn: 266186
|
| |
|
|
|
|
| |
C++17.
llvm-svn: 262753
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
OpenCL Extension v1.2 s9.5 allows half precision floating point
type literals with suffices h or H when cl_khr_fp16 is enabled.
Example: half x = 1.0h;
Patch by Liu Yaxun (Sam)!
Differential Revision: http://reviews.llvm.org/D16865
llvm-svn: 261084
|
| |
|
|
|
|
| |
of digit separators.
llvm-svn: 260307
|
| |
|
|
|
|
|
|
| |
NumericLiteralParser.
There were a couple slight variations between the two copies that I don't believe were intentional. For example, only one of the paths checked for digit separations proceeding a '.', but I think the lexer itself splits the token if a digit separator proceeds a period.
llvm-svn: 259022
|
| |
|
|
|
|
| |
prefix properly.
llvm-svn: 257097
|
| |
|
|
| |
llvm-svn: 253119
|
| |
|
|
|
|
| |
emitted in the same place. NFC
llvm-svn: 252861
|
| |
|
|
|
|
|
|
|
| |
Our string literal parser copied any source-file new-line characters
into the execution string-literal. This is incorrect if the source-file
new-line character was a \r\n sequence because new-line characters are
merely \n.
llvm-svn: 248392
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
There is currently no support in MSVC for using i128 as an integer
literal suffix. In fact, there appears to be no evidence that they have
ever supported this feature in any of their compilers. This was an over
generalization of their actual feature and is a nasty source of bugs.
Why is it a source of bugs? Because most code in clang expects that
evaluation of an integer constant expression won't give them something
that 'long long' can't represent. Instead of providing a meaningful
feature, i128 gives us cute ways of exploding the compiler.
llvm-svn: 243243
|
| |
|
|
|
|
|
|
|
| |
While dereferencing ThisTokEnd is fine and we know that it's not in
[a-zA-Z0-9_.], ThisTokEnd[1] is really past the end.
Found by asan and with a little help from clang-fuzz.
llvm-svn: 233491
|
| |
|
|
|
|
|
| |
We know that the last accessible char is not in [a-zA-Z0-9_.] so we can
happily scan on as long as it is. No functionality change.
llvm-svn: 233490
|
| |
|
|
| |
llvm-svn: 233006
|
| |
|
|
|
|
|
|
|
|
| |
Simplify boolean expressions using `true` and `false` with `clang-tidy`
Patch by Richard Thomson.
Differential Revision: http://reviews.llvm.org/D8531
llvm-svn: 232999
|
| |
|
|
| |
llvm-svn: 221576
|
| |
|
|
|
|
| |
Changes diagnostic options, language standard options, diagnostic identifiers, diagnostic wording to use c++14 instead of c++1y. It also modifies related test cases to use the updated diagnostic wording.
llvm-svn: 215982
|
| |
|
|
|
|
| |
and count.
llvm-svn: 211763
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Something went wrong with r211426, it is an older version of this code
and should not have been committed. It was reverted with r211434.
Original commit message:
We didn't properly implement support for the sized integer suffixes.
Suffixes like i16 were essentially ignored instead of mapping them to
the appropriately sized integer type.
This fixes PR20008.
Differential Revision: http://reviews.llvm.org/D4132
llvm-svn: 211441
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r211426.
This broke the arm bots. The crash can be reproduced on X86 by running.
./bin/clang -cc1 -fsyntax-only -verify -fms-extensions ~/llvm/clang/test/Lexer/ms-extensions.c -triple arm-linux
llvm-svn: 211434
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We didn't properly implement support for the sized integer suffixes.
Suffixes like i16 were essentially ignored instead of mapping them to
the appropriately sized integer type.
This fixes PR20008.
Differential Revision: http://reviews.llvm.org/D4132
llvm-svn: 211426
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3963
llvm-svn: 209859
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The limits on the number of fix-it hints and ranges attached to a
diagnostic are arbitrary and don't apply universally to all users of the
DiagnosticsEngine. The way the limits are enforced may lead to diagnostics
generating invalid sets of fixes. I suggest removing the limits, which will also
simplify the implementation.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D3879
llvm-svn: 209468
|
| |
|
|
| |
llvm-svn: 209083
|
| |
|
|
|
|
|
|
| |
digits. Turns out we have completely separate lexing codepaths for floating
point numbers depending on whether or not they start with a zero. Who knew...
=)
llvm-svn: 206932
|
| |
|
|
|
|
| |
operator==
llvm-svn: 203373
|
| |
|
|
| |
llvm-svn: 201532
|
| |
|
|
|
|
|
|
| |
miscompilation.
Investigating yet. It seems msc16 miscompiles s[1] to be folded.
llvm-svn: 191485
|
| |
|
|
| |
llvm-svn: 191424
|
| |
|
|
|
|
| |
Dennett.
llvm-svn: 191420
|
| |
|
|
|
|
| |
yet approved by full committee, but was unanimously supported by EWG.
llvm-svn: 191417
|
| |
|
|
|
|
|
|
| |
literal operators. Also, for now, allow the proposed C++1y "il", "i", and "if"
suffixes too. (Will revert the latter if LWG decides not to go ahead with that
change after all.)
llvm-svn: 191274
|
| |
|
|
|
|
| |
Patch by Eelis van der Weegen.
llvm-svn: 190971
|
| |
|
|
|
|
| |
literals.
llvm-svn: 188918
|