summaryrefslogtreecommitdiffstats
path: root/clang/lib/Lex/LiteralSupport.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [APFloat] Fix checked error assert failuresEhud Katz2020-01-091-5/+3
| | | | | | | | | | | `APFLoat::convertFromString` returns `Expected` result, which must be "checked" if the LLVM_ENABLE_ABI_BREAKING_CHECKS preprocessor flag is set. To mark an `Expected` result as "checked" we must consume the `Error` within. In many cases, we are only interested in knowing if an error occured, without the need to examine the error info. This is achieved, easily, with the `errorToBool()` API.
* [APFloat] Fix compilation warningsEhud Katz2020-01-061-2/+5
|
* [APFloat] Add recoverable string parsing errors to APFloatEhud Katz2020-01-061-1/+4
| | | | | | Implementing the APFloat part in PR4745. Differential Revision: https://reviews.llvm.org/D69770
* [CUDA][HIP] Do not diagnose use of _Float16Yaxun Liu2019-01-291-2/+5
| | | | | | | | | | | r352221 caused regressions in CUDA/HIP since device function may use _Float16 whereas host does not support it. In this case host compilation should not diagnose usage of _Float16 in device functions or variables. For now just do not diagnose _Float16 for CUDA/HIP. In the future we should have more precise check. Differential Revision: https://reviews.llvm.org/D57369 llvm-svn: 352488
* Remove F16 literal support based on Float16 support.Erich Keane2019-01-251-4/+5
| | | | | | | | | Float16 support was disabled recently on many platforms, however that commit still allowed literals of Float16 type to work. This commit removes those based on the same logic as Float16 disable. Change-Id: I72243048ae2db3dc47bd3d699843e3edf9c395ea llvm-svn: 352229
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* Fix clang -Wimplicit-fallthrough warnings across llvm, NFCReid Kleckner2018-11-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch should not introduce any behavior changes. It consists of mostly one of two changes: 1. Replacing fall through comments with the LLVM_FALLTHROUGH macro 2. Inserting 'break' before falling through into a case block consisting of only 'break'. We were already using this warning with GCC, but its warning behaves slightly differently. In this patch, the following differences are relevant: 1. GCC recognizes comments that say "fall through" as annotations, clang doesn't 2. GCC doesn't warn on "case N: foo(); default: break;", clang does 3. GCC doesn't warn when the case contains a switch, but falls through the outer case. I will enable the warning separately in a follow-up patch so that it can be cleanly reverted if necessary. Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu Differential Revision: https://reviews.llvm.org/D53950 llvm-svn: 345882
* Remove trailing spaceFangrui Song2018-07-301-3/+3
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* Enable C++2a Chrono LiteralsErich Keane2018-07-191-3/+8
| | | | | | | | | | | | | | | | | | | C++2a via http://wg21.link/p0355 permits the library literals of 'd' and 'y'. This patch enables them in the Lexer so that they can be properly parsed. Note that 'd' gets confused with the hex character, so modifications to how octal, binary, and decimal numbers are parsed were required. Since this is simply making previously invalid code legal, this should be fine. Hex still greedily parses the 'd' as a hexit, since it would a: violate [lex.ext]p1 b: break existing code. Differential Revision: https://reviews.llvm.org/D49504 llvm-svn: 337454
* [Fixed Point Arithmetic] Fix for bug where integer literals could be treated ↵Leonard Chan2018-07-171-5/+10
| | | | | | | | | | | | | | | | as fixed point literals This addresses a bug brought up in https://bugs.llvm.org/show_bug.cgi?id=38161 where integer literals could be treated as fixed point types and throw errors related to fixed point types when the 'k' or 'r' suffix used. The fix also addresses the second issue brought up with the assertion by not treating integers as fixed point types in the first place. Integers that have suffixes 'k' and 'r' now throw the error `invalid suffix 'k/r' on integer constant`. A few more tests were also added to ensure that fixed point types, and any errors/warnings related to them, are limited to C for now. Prior discussion also at https://reviews.llvm.org/D46915. Differential Revision: https://reviews.llvm.org/D49327 llvm-svn: 337289
* PR15730/PR16986 Allow dependently typed vector_size types.Erich Keane2018-07-131-1/+1
| | | | | | | | | | | | | | | | | As listed in the above PRs, vector_size doesn't allow dependent types/values. This patch introduces a new DependentVectorType to handle a VectorType that has a dependent size or type. In the future, ALL the vector-types should be able to create one of these to handle dependent types/sizes as well. For example, DependentSizedExtVectorType could likely be switched to just use this instead, though that is left as an exercise for the future. Differential Revision: https://reviews.llvm.org/D49045 llvm-svn: 337036
* [Fixed Point Arithmetic] Fixed Point Precision Bits and Fixed Point LiteralsLeonard Chan2018-06-201-2/+151
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This diff includes the logic for setting the precision bits for each primary fixed point type in the target info and logic for initializing a fixed point literal. Fixed point literals are declared using the suffixes ``` hr: short _Fract uhr: unsigned short _Fract r: _Fract ur: unsigned _Fract lr: long _Fract ulr: unsigned long _Fract hk: short _Accum uhk: unsigned short _Accum k: _Accum uk: unsigned _Accum ``` Errors are also thrown for illegal literal values ``` unsigned short _Accum u_short_accum = 256.0uhk; // expected-error{{the integral part of this literal is too large for this unsigned _Accum type}} ``` Differential Revision: https://reviews.llvm.org/D46915 llvm-svn: 335148
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-2/+2
| | | | | | | | | | | | | | | | | | | 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
* [Lex] Fix handling numerical literals ending with ' and signed exponent.Volodymyr Sapsai2018-02-061-9/+15
| | | | | | | | | | | | | | | | | | | | | | | | | For input `0'e+1` lexer tokenized as numeric constant only `0'e`. Later NumericLiteralParser skipped 0 and ' as digits and parsed `e+1` as valid exponent going past the end of the token. Because it didn't mark numeric literal as having an error, it continued parsing and tried to expandUCNs with StringRef of length -2. The fix is not to parse exponent when we reached the end of token. Discovered by OSS-Fuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4588 rdar://problem/36076719 Reviewers: rsmith, t.p.northover Reviewed By: rsmith Subscribers: cfe-commits, jkorous-apple Differential Revision: https://reviews.llvm.org/D41834 llvm-svn: 324419
* Now that C++17 is official (https://www.iso.org/standard/68564.html), start ↵Aaron Ballman2017-12-041-1/+1
| | | | | | changing the C++1z terminology over to C++17. NFC intended, these are all mechanical changes. llvm-svn: 319688
* Recommit "Add _Float16 as a C/C++ source language type"Sjoerd Meijer2017-09-081-0/+9
| | | | | | | | This is a recommit of r312781; in some build configurations variable names are omitted, so changed the new regression test accordingly. llvm-svn: 312794
* Revert "Add _Float16 as a C/C++ source language type"Sjoerd Meijer2017-09-081-9/+0
| | | | | | | The clang-with-lto-ubuntu bot didn't like the new regression test, revert while I investigate the issue. llvm-svn: 312784
* Add _Float16 as a C/C++ source language typeSjoerd Meijer2017-09-081-0/+9
| | | | | | | | | | | 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
* Rename cxx1z -> cxx17 across all diagnostic IDs.Richard Smith2017-08-131-1/+1
| | | | llvm-svn: 310805
* Reapply Sema: allow imaginary constants via GNU extension if UDL overloads ↵Tim Northover2017-08-091-24/+20
| | | | | | | | | | | | | | | | | | 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
* Revert "Lexer: always allow imaginary constants in GNU mode."Tim Northover2017-08-081-1/+1
| | | | | | | This reverts r310423. It was committed by mistake, I intended to commit the improved diagnostics for implicit conversions instead. llvm-svn: 310426
* Lexer: always allow imaginary constants in GNU mode.Tim Northover2017-08-081-1/+1
| | | | llvm-svn: 310423
* Added LLVM_FALLTHROUGH to address warning: this statement may fall through + ↵Galina Kistanova2017-06-031-4/+11
| | | | | | formatted. NFC. llvm-svn: 304642
* Revert "Sema: allow imaginary constants via GNU extension if UDL overloads ↵Tim Northover2017-05-241-20/+24
| | | | | | | | | not present." This reverts commit r303697. It broke libc++ tests that were specifically checking incompatibility in C++14 mode. llvm-svn: 303813
* Fix 'set but not used' [-Wunused-but-set-variable] warningSimon Pilgrim2017-05-241-2/+0
| | | | llvm-svn: 303734
* Sema: allow imaginary constants via GNU extension if UDL overloads not present.Tim Northover2017-05-231-25/+20
| | | | | | | | | | | | | 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
* Allow lexer to handle string_view literals. Patch from Anton Bikineev.Eric Fiselier2016-12-301-0/+9
| | | | | | | This implements the compiler side of p0403r0. This patch was reviewed as https://reviews.llvm.org/D26829. llvm-svn: 290744
* Move UTF functions into namespace llvm.Justin Lebar2016-09-301-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix some Clang-tidy modernize-use-using and Include What You Use warnings; ↵Eugene Zelenko2016-09-071-3/+13
| | | | | | | | other minor fixes. Differential revision: https://reviews.llvm.org/D24115 llvm-svn: 280870
* [NFC] Header cleanupMehdi Amini2016-07-181-0/+1
| | | | | | | | | | 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
* Enable support for __float128 in Clang and enable it on pertinent platformsNemanja Ivanovic2016-05-091-2/+11
| | | | | | | | | | | | | | | | | | 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
* Revert 266186 as it breaks anything that includes type_traits on some platformsNemanja Ivanovic2016-04-151-11/+2
| | | | | | | | | | 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
* Enable support for __float128 in ClangNemanja Ivanovic2016-04-131-2/+11
| | | | | | | | | | | | | | | | 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
* Update diagnostics now that hexadecimal literals look likely to be part of ↵Richard Smith2016-03-041-4/+10
| | | | | | C++17. llvm-svn: 262753
* [OpenCL] Added half type literal with suffix h.Anastasia Stulova2016-02-171-2/+12
| | | | | | | | | | | | | 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
* PR26349: correctly check whether a digit sequence is empty in the presence ↵Richard Smith2016-02-091-6/+8
| | | | | | of digit separators. llvm-svn: 260307
* [Lex] Share some common code between decimal and octal parsing in ↵Craig Topper2016-01-281-61/+47
| | | | | | | | 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
* Properly track that a character literal is UTF-8, and pretty print the ↵Aaron Ballman2016-01-071-0/+1
| | | | | | prefix properly. llvm-svn: 257097
* Use %select to merge similar diagnostics. NFCCraig Topper2015-11-141-7/+7
| | | | llvm-svn: 253119
* Use %select to merge two diagnostics that only differ in one word and are ↵Craig Topper2015-11-121-3/+2
| | | | | | emitted in the same place. NFC llvm-svn: 252861
* [Lex] A source-file new-line in a raw string literal results in a new-lineDavid Majnemer2015-09-231-4/+17
| | | | | | | | | 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
* [MS Extensions] Remove support for the i128 integer literal suffixDavid Majnemer2015-07-261-4/+1
| | | | | | | | | | | | | 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
* [lex] Don't read past the end of the bufferBenjamin Kramer2015-03-291-3/+4
| | | | | | | | | 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
* [lex] Turn range checks into asserts.Benjamin Kramer2015-03-291-44/+36
| | | | | | | 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
* Make Oveflow tracking more legible (CR feedback from Richard Smith on r232999)David Blaikie2015-03-231-1/+2
| | | | llvm-svn: 233006
* Refactor: Simplify boolean expresssions in lib/LexDavid Blaikie2015-03-231-1/+1
| | | | | | | | | | Simplify boolean expressions using `true` and `false` with `clang-tidy` Patch by Richard Thomson. Differential Revision: http://reviews.llvm.org/D8531 llvm-svn: 232999
* [c++1z] Support for u8 character literals.Richard Smith2014-11-081-2/+6
| | | | llvm-svn: 221576
* C++1y is now C++14!Aaron Ballman2014-08-191-4/+4
| | | | | | 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
* Convert StringLiteralParser constructor to use ArrayRef instead of a pointer ↵Craig Topper2014-06-261-13/+13
| | | | | | and count. llvm-svn: 211763
* Lex: Use the correct types for MS integer suffixesDavid Majnemer2014-06-211-11/+10
| | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud