| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
------------------------------------------------------------------------
r338934 | vsapsai | 2018-08-04 01:12:37 +0200 (Sat, 04 Aug 2018) | 29 lines
[Preprocessor] Allow libc++ to detect when aligned allocation is unavailable.
Libc++ needs to know when aligned allocation is supported by clang, but is
otherwise unavailable at link time. Otherwise, libc++ will incorrectly end up
generating calls to `__builtin_operator_new`/`__builtin_operator_delete` with
alignment arguments.
This patch implements the following changes:
* The `__cpp_aligned_new` feature test macro to no longer be defined when
aligned allocation is otherwise enabled but unavailable.
* The Darwin driver no longer passes `-faligned-alloc-unavailable` when the
user manually specifies `-faligned-allocation` or `-fno-aligned-allocation`.
* Instead of a warning Clang now generates a hard error when an aligned
allocation or deallocation function is referenced but unavailable.
Patch by Eric Fiselier.
Reviewers: rsmith, vsapsai, erik.pilkington, ahatanak, dexonsmith
Reviewed By: rsmith
Subscribers: Quuxplusone, cfe-commits
Differential Revision: https://reviews.llvm.org/D45015
------------------------------------------------------------------------
llvm-svn: 339660
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add a flag `-fno-digraphs` to disable digraphs in the lexer, similar to `-fno-operator-names` which disables alternative names for C++ operators.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D48266
llvm-svn: 337232
|
|
|
|
| |
llvm-svn: 334677
|
|
|
|
|
|
| |
indicate support for P0620R0.
llvm-svn: 333587
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is not yet part of any C++ working draft, and so is controlled by the flag
-fchar8_t rather than a -std= flag. (The GCC implementation is controlled by a
flag with the same name.)
This implementation is experimental, and will be removed or revised
substantially to match the proposal as it makes its way through the C++
committee.
llvm-svn: 331244
|
|
|
|
|
|
|
|
|
| |
This patch adds -fsanitize=kernel-hwaddress flag, that essentially enables
-hwasan-kernel=1 -hwasan-recover=1 -hwasan-match-all-tag=0xff.
Differential Revision: https://reviews.llvm.org/D45046
llvm-svn: 330044
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARC mode.
Declaring __strong pointer fields in structs was not allowed in
Objective-C ARC until now because that would make the struct non-trivial
to default-initialize, copy/move, and destroy, which is not something C
was designed to do. This patch lifts that restriction.
Special functions for non-trivial C structs are synthesized that are
needed to default-initialize, copy/move, and destroy the structs and
manage the ownership of the objects the __strong pointer fields point
to. Non-trivial structs passed to functions are destructed in the callee
function.
rdar://problem/33599681
Differential Revision: https://reviews.llvm.org/D41228
llvm-svn: 326307
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix makes the loop in LexAngledStringLiteral more like the loops in
LexStringLiteral, LexCharConstant. When we skip a character after
backslash, we need to check if we reached the end of the file instead of
reading the next character unconditionally.
Discovered by OSS-Fuzz:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3832
rdar://problem/35572754
Reviewers: arphaman, kcc, rsmith, dexonsmith
Reviewed By: rsmith, dexonsmith
Subscribers: cfe-commits, rsmith, dexonsmith
Differential Revision: https://reviews.llvm.org/D41423
llvm-svn: 322390
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically, warn if:
* we find a character that the language standard says we must treat as an
identifier, and
* that character is not reasonably an identifier character (it's a punctuation
character or similar), and
* it renders identically to a valid non-identifier character in common
fixed-width fonts.
Some tools "helpfully" substitute the surprising characters for the expected
characters, and replacing semicolons with Greek question marks is a common
"prank".
llvm-svn: 320697
|
|
|
|
|
|
| |
This is C++14 with conforming GNU extensions.
llvm-svn: 320250
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Driver, frontend and LLVM codegen for HWASan.
A clone of ASan, basically.
Reviewers: kcc, pcc, alekseyshl
Subscribers: srhines, javed.absar, cfe-commits
Differential Revision: https://reviews.llvm.org/D40936
llvm-svn: 320232
|
|
|
|
|
|
| |
No CodeGen support for MSABI yet, we don't know how to mangle this there.
llvm-svn: 319513
|
|
|
|
| |
llvm-svn: 319509
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the logic for determining the `wchar_t` type information into the
driver. Rather than passing the single bit of information of
`-fshort-wchar` indicate to the frontend the desired type of `wchar_t`
through a new `-cc1` option of `-fwchar-type` and indicate the
signedness through `-f{,no-}signed-wchar`. This replicates the current
logic which was spread throughout Basic into the
`RenderCharacterOptions`.
Most of the changes to the tests are to ensure that the frontend uses
the correct type. Add a new test set under `test/Driver/wchar_t.c` to
ensure that we calculate the proper types for the various cases.
llvm-svn: 315126
|
|
|
|
|
|
|
|
| |
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: 310978
|
|
|
|
|
|
|
|
|
|
| |
The %T lit expansion expands to a common directory shared between all the tests in the same directory, which is unexpected and unintuitive, and more importantly, it's been a source of subtle race conditions and flaky tests. In https://reviews.llvm.org/D35396, it was agreed that it would be best to simply ban %T and only keep %t, which is unique to each test. When a test needs a temporary directory, it can just create one using mkdir %t.
This patch removes %T in clang.
Differential Revision: https://reviews.llvm.org/D36437
llvm-svn: 310950
|
|
|
|
| |
llvm-svn: 310804
|
|
|
|
|
|
| |
C++17 and before.
llvm-svn: 310803
|
|
|
|
| |
llvm-svn: 310694
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 309054
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, a preamble only included #if blocks (and friends like
ifdef) if there was a corresponding #endif before any declaration or
definition. The problem is that any header file that uses include guards
will not have a preamble generated, which can make code-completion very
slow.
To prevent errors about unbalanced preprocessor conditionals in the
preamble, and unbalanced preprocessor conditionals after a preamble
containing unfinished conditionals, the conditional stack is stored
in the pch file.
This fixes PR26045.
Differential Revision: http://reviews.llvm.org/D15994
llvm-svn: 304207
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This patch is needed so that Libc++ can actually tess if Clang supports coroutines, instead of just paying lip service with a partial implementation. Otherwise the libc++ test suite will fail against older versions of Clang
Reviewers: GorNishanov, rsmith
Reviewed By: GorNishanov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33536
llvm-svn: 303867
|
|
|
|
|
|
| |
comments if trigraphs are disabled in the current language.
llvm-svn: 300609
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, if an escaped newline was followed by a newline or a nul, we'd lex
the escaped newline as a bogus space character. This led to a bunch of
different broken corner cases:
For the pattern "\\\n\0#", we would then have a (horizontal) space whose
spelling ends in a newline, and would decide that the '#' is at the start of a
line, and incorrectly start preprocessing a directive in the middle of a
logical source line. If we were already in the middle of a directive, this
would result in our attempting to process multiple directives at the same time!
This resulted in crashes, asserts, and hangs on invalid input, as discovered by
fuzz-testing.
For the pattern "\\\n" at EOF (with an implicit following nul byte), we would
produce a bogus trailing space character with spelling "\\\n". This was mostly
harmless, but would lead to clang-format getting confused and misformatting in
rare cases. We now produce a trailing EOF token with spelling "\\\n",
consistent with our handling for other similar cases -- an escaped newline is
always part of the token containing the next character, if any.
For the pattern "\\\n\n", this was somewhat more benign, but would produce an
extraneous whitespace token to clients who care about preserving whitespace.
However, it turns out that our lexing for line comments was relying on this bug
due to an off-by-one error in its computation of the end of the comment, on the
slow path where the comment might contain escaped newlines.
llvm-svn: 300515
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: When using the C preprocessor with assembly files, either with a
capital `S` file extension, or with `-xassembler-with-cpp`, the Unicode escape
sequence `\u` is ignored. The `\u` pattern can be used for expanding a macro
argument that starts with `u`.
Author: Salman Arif <salman.arif@arm.com>
Reviewers: rengolin, olista01
Reviewed By: olista01
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31765
llvm-svn: 299754
|
|
|
|
|
|
|
|
| |
them via feature test macro __cpp_constexpr.
Thanks to Faisal for implementing this feature!
llvm-svn: 295791
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This is a patch for PR31836. As the bug replaces the path separators in the included file name with the characters following them, the test script makes sure that there's no "Ccase-insensitive-include-pr31836.h" in the warning message.
Reviewers: rsmith, eric_niebler
Reviewed By: eric_niebler
Subscribers: karies, cfe-commits
Differential Revision: https://reviews.llvm.org/D30000
llvm-svn: 295779
|
|
|
|
|
|
| |
feature-test macro, and mark feature as done on status page.
llvm-svn: 295011
|
|
|
|
|
|
|
|
|
| |
by providing a memchr builtin that returns char* instead of void*.
Also add a __has_feature flag to indicate the presence of constexpr forms of
the relevant <string> functions.
llvm-svn: 292555
|
|
|
|
|
|
| |
latest (provisional) draft of SD-6.
llvm-svn: 290082
|
|
|
|
| |
llvm-svn: 290081
|
|
|
|
| |
llvm-svn: 288452
|
|
|
|
| |
llvm-svn: 283724
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Also makes -fcoroutines_ts to be both a Driver and CC1 flag.
Patch mostly by EricWF.
Reviewers: rnk, cfe-commits, rsmith, EricWF
Subscribers: mehdi_amini
Differential Revision: https://reviews.llvm.org/D25130
llvm-svn: 283064
|
|
|
|
|
|
| |
corresponding SD-6 macro.
llvm-svn: 282652
|
|
|
|
|
|
|
| |
not reflect the final chosen names, but supporting them now seems to have
little downside.
llvm-svn: 282629
|
|
|
|
|
|
| |
macros).
llvm-svn: 282627
|
|
|
|
| |
llvm-svn: 282622
|
|
|
|
|
|
| |
'module' and 'import' as keywords when the flag is specified.
llvm-svn: 276508
|
|
|
|
|
|
|
|
|
|
|
| |
non-portable #include and #import paths.
Differential Revision: http://reviews.llvm.org/D19843
Corresponding LLVM change: http://reviews.llvm.org/D19842
Re-commit of r272562 after addressing clang-x86-win2008-selfhost failure.
llvm-svn: 272584
|
|
|
|
| |
llvm-svn: 272572
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
non-portable #include and #import paths.
Differential Revision: http://reviews.llvm.org/D19843
Corresponding LLVM change: http://reviews.llvm.org/D19842
Re-commit after addressing issues with of generating too many warnings for Windows and asan test failures.
Patch by Eric Niebler
llvm-svn: 272562
|
|
|
|
| |
llvm-svn: 271761
|
|
|
|
|
|
|
|
|
|
|
| |
non-portable #include and #import paths.
Differential Revision: http://reviews.llvm.org/D19843
Corresponding LLVM change: http://reviews.llvm.org/D19842
Patch by Eric Niebler
llvm-svn: 271708
|