- Sep 04, 2016
-
-
Joerg Sonnenberger authored
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280607 91177308-0d34-0410-b5e6-96231b3b80d8
-
- Sep 03, 2016
-
-
Craig Topper authored
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280597 91177308-0d34-0410-b5e6-96231b3b80d8
-
Craig Topper authored
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280596 91177308-0d34-0410-b5e6-96231b3b80d8
-
Aaron Ballman authored
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280591 91177308-0d34-0410-b5e6-96231b3b80d8
-
Niels Ole Salscheider authored
Differential Revision: https://reviews.llvm.org/D23957 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280587 91177308-0d34-0410-b5e6-96231b3b80d8
-
Nico Weber authored
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280580 91177308-0d34-0410-b5e6-96231b3b80d8
-
Nico Weber authored
Some Windows SDK classes, for example Windows::Storage::Streams::IBufferByteAccess, use the ATL way of spelling attributes: [uuid("....")] class IBufferByteAccess {}; To be able to use __uuidof() to grab the uuid off these types, clang needs to support uuid as a Microsoft attribute. There was already code to skip Microsoft attributes, extend that to look for uuid and parse it. Use the new "Microsoft" attribute type added in r280575 (and r280574, r280576) for this. Final part of https://reviews.llvm.org/D23895 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280578 91177308-0d34-0410-b5e6-96231b3b80d8
-
Nico Weber authored
There was already a function that moved attributes off the declspec into an attribute list for attributes applying to the type, teach that function to also move Microsoft attributes around and rename it to match its new broader role. Nothing uses Microsoft attributes yet, so no behavior change. Part of https://reviews.llvm.org/D23895 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280576 91177308-0d34-0410-b5e6-96231b3b80d8
-
Nico Weber authored
This is for attributes in []-delimited lists preceding a class, like e.g. `[uuid("...")] class Foo {};` Not used by anything yet, so no behavior change. Part of https://reviews.llvm.org/D23895 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280575 91177308-0d34-0410-b5e6-96231b3b80d8
-
Nico Weber authored
into ParseDeclOrFunctionDefInternal() (which is called by MaybeParseMicrosoftAttributes()), so that the attributes can be stored in the DeclSpec. No behavior change yet, part of https://reviews.llvm.org/D23895 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280574 91177308-0d34-0410-b5e6-96231b3b80d8
-
Nico Weber authored
The comment starting with "ParseDeclarationOrFunctionDefinition -" is above a function called ParseDeclOrFunctionDefInternal. Fix the comment by not mentioning a function name, like the style guide requests nowadays. No behavior change. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280572 91177308-0d34-0410-b5e6-96231b3b80d8
-
George Burgess IV authored
We have invariants we like to guarantee for the `ImplicitConversionKind`s in a `StandardConversionSequence`. These weren't being upheld in code that r280553 touched, so Richard suggested that we should fix that. See D24113. I'm not entirely sure how to go about testing this, so no test case is included. Suggestions welcome. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280562 91177308-0d34-0410-b5e6-96231b3b80d8
-
Yunzhong Gao authored
Clang tests for verifying the following syntaxes: 1. 0xNN and NNh are accepted as valid hexadecimal numbers, but 0xNNh is not. 0xNN and NNh may come with optional U or L suffix. 2. NNb is accepted as a valid binary (base-2) number, but 0bNN is not. NNb may come with optional U or L suffix. Differential Revision: https://reviews.llvm.org/D22112 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280556 91177308-0d34-0410-b5e6-96231b3b80d8
-
George Burgess IV authored
This patch allows us to perform incompatible pointer conversions when resolving overloads in C. So, the following code will no longer fail to compile (though it will still emit warnings, assuming the user hasn't opted out of them): ``` void foo(char *) __attribute__((overloadable)); void foo(int) __attribute__((overloadable)); void callFoo() { unsigned char bar[128]; foo(bar); // selects the char* overload. } ``` These conversions are ranked below all others, so: A. Any other viable conversion will win out B. If we had another incompatible pointer conversion in the example above (e.g. `void foo(int *)`), we would complain about an ambiguity. Differential Revision: https://reviews.llvm.org/D24113 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280553 91177308-0d34-0410-b5e6-96231b3b80d8
-
- Sep 02, 2016
-
-
Eric Fiselier authored
Summary: This attribute specifies expectations about the initialization of static and thread local variables. Specifically that the variable has a [constant initializer](http://en.cppreference.com/w/cpp/language/constant_initialization) according to the rules of [basic.start.static]. Failure to meet this expectation will result in an error. Static objects with constant initializers avoid hard-to-find bugs caused by the indeterminate order of dynamic initialization. They can also be safely used by other static constructors across translation units. This attribute acts as a compile time assertion that the requirements for constant initialization have been met. Since these requirements change between dialects and have subtle pitfalls it's important to fail fast instead of silently falling back on dynamic initialization. ```c++ // -std=c++14 #define SAFE_STATIC __attribute__((require_constant_initialization)) static struct T { constexpr T(int) {} ~T(); }; SAFE_STATIC T x = {42}; // OK. SAFE_STATIC T y = 42; // error: variable does not have a constant initializer // copy initialization is not a constant expression on a non-literal type. ``` This attribute can only be applied to objects with static or thread-local storage duration. Reviewers: majnemer, rsmith, aaron.ballman Subscribers: jroelofs, cfe-commits Differential Revision: https://reviews.llvm.org/D23385 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280525 91177308-0d34-0410-b5e6-96231b3b80d8
-
Eric Fiselier authored
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280521 91177308-0d34-0410-b5e6-96231b3b80d8
-
Aaron Ballman authored
Based on post-commit feedback over IRC with dblaikie, ideally, we should have a SmallVector constructor that accepts anything which can supply a range via ADL begin()/end() calls so that we can construct the SmallVector directly from anything range-like. Since that doesn't exist right now, use a local variable instead of calling getAssocExprs() twice; NFC. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280520 91177308-0d34-0410-b5e6-96231b3b80d8
-
Eric Fiselier authored
Summary: This attribute specifies expectations about the initialization of static and thread local variables. Specifically that the variable has a [constant initializer](http://en.cppreference.com/w/cpp/language/constant_initialization) according to the rules of [basic.start.static]. Failure to meet this expectation will result in an error. Static objects with constant initializers avoid hard-to-find bugs caused by the indeterminate order of dynamic initialization. They can also be safely used by other static constructors across translation units. This attribute acts as a compile time assertion that the requirements for constant initialization have been met. Since these requirements change between dialects and have subtle pitfalls it's important to fail fast instead of silently falling back on dynamic initialization. ```c++ // -std=c++14 #define SAFE_STATIC __attribute__((require_constant_initialization)) static struct T { constexpr T(int) {} ~T(); }; SAFE_STATIC T x = {42}; // OK. SAFE_STATIC T y = 42; // error: variable does not have a constant initializer // copy initialization is not a constant expression on a non-literal type. ``` This attribute can only be applied to objects with static or thread-local storage duration. Reviewers: majnemer, rsmith, aaron.ballman Subscribers: jroelofs, cfe-commits Differential Revision: https://reviews.llvm.org/D23385 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280516 91177308-0d34-0410-b5e6-96231b3b80d8
-
Martin Probst authored
Summary: When formatting source code that needs both requoting and reindentation, merge the replacements to avoid erroring out for conflicting replacements. Also removes the misleading Replacements parameter from the TokenAnalyzer API. Reviewers: djasper Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D24155 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280487 91177308-0d34-0410-b5e6-96231b3b80d8
-
Martin Probst authored
Summary: Default imports appear outside of named bindings in curly braces: import A from 'a'; import A, {symbol} from 'a'; Reviewers: djasper Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D23973 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280486 91177308-0d34-0410-b5e6-96231b3b80d8
-
Martin Probst authored
Summary: User feedback is that they expect *all* imports to be sorted if any import was affected by a change, not just imports up to the first non-affected line, as clang-format currently does. Reviewers: djasper Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D23972 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280485 91177308-0d34-0410-b5e6-96231b3b80d8
-
Aaron Ballman authored
Allow a C11 generic selection expression to select a function with the overloadable attribute as the result expression without crashing. This fixes PR30201. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280483 91177308-0d34-0410-b5e6-96231b3b80d8
-
Richard Smith authored
look for a corresponding file, since we're not going to read it anyway. No observable behavior change (though we now avoid pointlessly trying to stat or open a file named "-"). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280436 91177308-0d34-0410-b5e6-96231b3b80d8
-
Richard Smith authored
during this function, and to avoid rolling back changes to the module manager's data structures. Instead, we defer registering the module file until after we have successfully finished loading it. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280434 91177308-0d34-0410-b5e6-96231b3b80d8
-
Alexander Shaposhnikov authored
The class MismatchingNewDeleteDetector is in lib/Sema/SemaExprCXX.cpp inside the anonymous namespace. This diff reorders the fields and removes the excessive padding. Test plan: make -j8 check-clang Differential revision: https://reviews.llvm.org/D23898 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280426 91177308-0d34-0410-b5e6-96231b3b80d8
-
Derek Schuff authored
Summary: We want wasm and asmjs to have matching ABIs, and right now asmjs uses unsigned int for its size_t. This causes exported symbols in libcxx to not match and can cause weird breakage where libcxx doesn't get linked as a result. Long-term we probably want wasm32, wasm64, and asmjs to all use unsigned long, but that would cause unnecessary ABI churn for asmjs so defer that until we can make all the ABI changes at once. Patch by Jacob Gravelle Differential Revision: https://reviews.llvm.org/D24134 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280420 91177308-0d34-0410-b5e6-96231b3b80d8
-
- Sep 01, 2016
-
-
Richard Smith authored
textually included, create an ImportDecl just as we would if we reached a #include of any other modular header. This is necessary in order to correctly determine the set of variables to initialize for an imported module. This should hopefully make the modules selfhost buildbot green again. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280409 91177308-0d34-0410-b5e6-96231b3b80d8
-
Chris Bieneman authored
This correctly connects compiler-rt-test-depends to test-depends and check-compiler-rt to check-all. Based on LLVM r280392, and Compiler-RT r280393. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280394 91177308-0d34-0410-b5e6-96231b3b80d8
-
Aleksei Sidorin authored
This patch also introduces AnalysisOrderChecker which is intended for testing of callback call correctness. Differential Revision: https://reviews.llvm.org/D23804 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280367 91177308-0d34-0410-b5e6-96231b3b80d8
-
Aleksei Sidorin authored
Some FileIDs that may be used by PlistDiagnostics were not added while building a list of pieces. This caused assertion violation in GetFID() function. This patch adds some missing FileIDs to avoid the assertion. It also contains small refactoring of PlistDiagnostics::FlushDiagnosticsImpl(). Patch by Aleksei Sidorin, Ilya Palachev. Differential Revision: https://reviews.llvm.org/D22090 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280360 91177308-0d34-0410-b5e6-96231b3b80d8
-
Honggyu Kim authored
Since some profiling tools, such as gprof, ftrace, and uftrace, use -pg option to generate a mcount function call at the entry of each function. Function invocation can be detected by this hook function. But mcount insertion is done before function inlining phase in clang, sometime a function that already has a mcount call can be inlined in the middle of another function. This patch adds an attribute "counting-function" to each function rather than emitting the mcount call directly in frontend so that this attribute can be processed in backend. Then the mcount calls can be properly inserted in backend after all the other optimizations are completed. Link: https://llvm.org/bugs/show_bug.cgi?id=28660 Reviewers: hans, rjmccall, hfinkel, rengolin, compnerd Subscribers: shenhan, cfe-commits Differential Revision: https://reviews.llvm.org/D22666 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280355 91177308-0d34-0410-b5e6-96231b3b80d8
-
Aleksei Sidorin authored
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280352 91177308-0d34-0410-b5e6-96231b3b80d8
-
Honggyu Kim authored
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280337 91177308-0d34-0410-b5e6-96231b3b80d8
-
George Burgess IV authored
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280333 91177308-0d34-0410-b5e6-96231b3b80d8
-
Akira Hatanaka authored
declaration has a dependent type. This fixes a bug where clang errors out on a valid code. rdar://problem/28051467 Differential Revision: https://reviews.llvm.org/D24110 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280330 91177308-0d34-0410-b5e6-96231b3b80d8
-
Richard Smith authored
C++ language standard is not C++98. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280309 91177308-0d34-0410-b5e6-96231b3b80d8
-
Richard Smith authored
explicit specialization to a warning for C++98 mode (this is a defect report resolution, so per our informal policy it should apply in C++98), and turn the warning on by default for C++11 and later. In all cases where it fires, the right thing to do is to remove the pointless explicit instantiation. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280308 91177308-0d34-0410-b5e6-96231b3b80d8
-
Nick Lewycky authored
-fprofile-dir=path allows the user to specify where .gcda files should be emitted when the program is run. In particular, this is the first flag that causes the .gcno and .o files to have different paths, LLVM is extended to support this. -fprofile-dir= does not change the file name in the .gcno (and thus where lcov looks for the source) but it does change the name in the .gcda (and thus where the runtime library writes the .gcda file). It's different from a GCOV_PREFIX because a user can observe that the GCOV_PREFIX_STRIP will strip paths off of -fprofile-dir= but not off of a supplied GCOV_PREFIX. To implement this we split -coverage-file into -coverage-data-file and -coverage-notes-file to specify the two different names. The !llvm.gcov metadata node grows from a 2-element form {string coverage-file, node dbg.cu} to 3-elements, {string coverage-notes-file, string coverage-data-file, node dbg.cu}. In the 3-element form, the file name is already "mangled" with .gcno/.gcda suffixes, while the 2-element form left that to the middle end pass. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280306 91177308-0d34-0410-b5e6-96231b3b80d8
-
- Aug 31, 2016
-
-
David Blaikie authored
I tested the cases involving split-dwarf + gmlt + no-split-dwarf-inlining, but didn't verify the simpler case without gmlt. The logic is, admittedly, a little hairy, but seems about as simple as I could wrangle it. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280290 91177308-0d34-0410-b5e6-96231b3b80d8
-
Richard Smith authored
specifications under -fno-exceptions, just as we don't diagnose other exception specification mismatch errors. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280289 91177308-0d34-0410-b5e6-96231b3b80d8
-