October 2017 bump. #3
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
C11 standard refers to the unsigned counterpart of the type ptrdiff_t
in the paragraph 7.21.6.1p7 where it defines the format specifier %tu.
In Clang (in PrintfFormatString.cpp, lines 508-510) there is a FIXME for this case,
in particular, Clang didn't diagnose %tu issues at all, i.e.
it didn't emit any warnings on the code printf("%tu", 3.14).
In this diff we add a method getUnsignedPointerDiffType for getting the corresponding type
similarly to how it's already done in the other analogous cases (size_t, ssize_t, ptrdiff_t etc)
and fix -Wformat diagnostics for %tu plus the emitted fix-it as well.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D38270
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314470 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes nullability fix-it for `id<SomeProtocol>`. With this change nullability specifier is inserted after ">" instead of between "id" and "<". rdar://problem/34260995 Reviewers: jordan_rose, doug.gregor, ahatanak, arphaman Reviewed By: jordan_rose Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D38327 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314473 91177308-0d34-0410-b5e6-96231b3b80d8
…ro Definition. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314483 91177308-0d34-0410-b5e6-96231b3b80d8
…exing a macro definition. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314484 91177308-0d34-0410-b5e6-96231b3b80d8
…emory / immediate expressions Allow the proper recognition of Enum values and global variables inside ms inline-asm memory / immediate expressions, as they require some additional overhead and treated incorrect if doesn't early recognized. supersedes D33278, D35774 Differential Revision: https://reviews.llvm.org/D37413 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314494 91177308-0d34-0410-b5e6-96231b3b80d8
Patch by S. Gilles! Differential Revision: https://reviews.llvm.org/D28148 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314499 91177308-0d34-0410-b5e6-96231b3b80d8
This commit adds a refactoring engine design document that talks about the design and provides several example of how the engine can be used. Differential Revision: https://reviews.llvm.org/D37976 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314509 91177308-0d34-0410-b5e6-96231b3b80d8
… be able to handle non-Darwin targets Summary: Also makes them pass on Darwin, if the default target triple is a Linux triple. Reviewers: bruno, rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D38364 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314524 91177308-0d34-0410-b5e6-96231b3b80d8
Suspected failure due to LSan's atexit and exit interception behavior. Reviewers: kcc, kubamracek, bogner, hfinkel, alekseyshl, Hahnfeld, gtbercea Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D37810 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314526 91177308-0d34-0410-b5e6-96231b3b80d8
'InlineAsmIdentifierInfo' is now a struct - notify Sema.h it isn't a class anymore git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314529 91177308-0d34-0410-b5e6-96231b3b80d8
Apparently, the MSVC SDK has a strange implementation that causes a number of implicit functions as well as a template member function of the IUnknown type. This patch allows these as InterfaceLike types as well. Additionally, it corrects the behavior where extern-C++ wrapped around an Interface-Like type would permit an interface-like type to exist in a namespace. Differential Revision: https://reviews.llvm.org/D38303 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314557 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314558 91177308-0d34-0410-b5e6-96231b3b80d8
…tion and a function-style cast. This fires for cases such as T(x); ... where 'x' was previously declared and T is a type. This construct declares a variable named 'x' rather than the (probably expected) interpretation of a function-style cast of 'x' to T. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314570 91177308-0d34-0410-b5e6-96231b3b80d8
Differential Revision: https://reviews.llvm.org/D37840 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314571 91177308-0d34-0410-b5e6-96231b3b80d8
Differential Revision: https://reviews.llvm.org/D38162 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314572 91177308-0d34-0410-b5e6-96231b3b80d8
…meters in function name Differential Revision: https://reviews.llvm.org/D37596 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314573 91177308-0d34-0410-b5e6-96231b3b80d8
…nings in tests. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314580 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314581 91177308-0d34-0410-b5e6-96231b3b80d8
…geting *-win32.
This expects the warning;
File clang/test/SemaCXX/ms-iunknown-template-function.cpp Line 19: __declspec attribute 'novtable' is not supported
But for targeting *-win32, the warning is not seen.
error: 'warning' diagnostics expected but not seen:
File clang\test\SemaCXX\ms-iunknown-template-function.cpp Line 19 (directive at clang\test\SemaCXX\ms-iunknown-template-function.cpp:18): __declspec attribute 'novtable'
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314586 91177308-0d34-0410-b5e6-96231b3b80d8
- MacroArgs already knows the maximum number of arguments that can be supplied to the macro. No need to pass MacroInfo (information about the macro definition) to the call to getPreExpArgument (which by the way might benefit from being called getExpandedArgument() ?) for it to compute the number of arguments. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314593 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314600 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314605 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314623 91177308-0d34-0410-b5e6-96231b3b80d8
This patch relates to: https://reviews.llvm.org/D33666 This adds support for template parameters to be passed to the address_space attribute. The main goal is to add further flexibility to the attribute and allow for it to be used easily with templates. The main additions are a new type (DependentAddressSpaceType) alongside its TypeLoc and its mangling. As well as the logic required to support dependent address spaces which mainly resides in TreeTransform.h and SemaType.cpp. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314649 91177308-0d34-0410-b5e6-96231b3b80d8
Adding regression test for Dependent Address Spaces in relation to https://reviews.llvm.org/D33666 I forgot to svn add the test file before commiting the prior changes. I appologies. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314650 91177308-0d34-0410-b5e6-96231b3b80d8
…ith just TBAA access types This patch fixes misleading names of entities related to getting, setting and generation of TBAA access type descriptors. This is effectively an attempt to provide a review for D37826 by breaking it into smaller pieces. Differential Revision: https://reviews.llvm.org/D38404 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314657 91177308-0d34-0410-b5e6-96231b3b80d8
…sses This is part of D37826 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D38408 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314660 91177308-0d34-0410-b5e6-96231b3b80d8
Modifying a non-type template integer arguement that is causing errors in some builds as it's too large for 32-bit longs. This hopefully (and seems to when testing) should fix all of the build bot errors relating to this test. I also modified the name of the function call to be more apt. Differential Revision: https://reviews.llvm.org/D33666 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314668 91177308-0d34-0410-b5e6-96231b3b80d8
Simplified and generalized codegen for non-offloading part that works if offloading is failed or condition of the `if` clause is `false`. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314670 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314673 91177308-0d34-0410-b5e6-96231b3b80d8
… LValue base info Differential Revision: https://reviews.llvm.org/D38796 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315731 91177308-0d34-0410-b5e6-96231b3b80d8
…pers. It is not uncommon for the users to make their own wrappers around CoreFoundation's CFRetain and CFRelease functions that are defensive against null references. In such cases CFRetain is often incorrectly marked as CF_RETURNS_RETAINED. Ignore said annotation and treat such wrappers similarly to the regular CFRetain. rdar://problem/31699502 Differential Revision: https://reviews.llvm.org/D38877 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315736 91177308-0d34-0410-b5e6-96231b3b80d8
This commit actually brings clang-refactor to a usable state as it can now apply the refactoring changes to source files. The -selection option is now also fully supported. Differential Revision: https://reviews.llvm.org/D38402 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315738 91177308-0d34-0410-b5e6-96231b3b80d8
…ong with LValue base info", r315731. With this change we fail on the clang-x86_64-linux-selfhost-modules builder. Differential Revision: https://reviews.llvm.org/D38796 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315739 91177308-0d34-0410-b5e6-96231b3b80d8
The `nan` family of functions will inspect the contents of the parameter that they are passed. As a result, the function cannot be annotated as `const`. The documentation of the `const` attribute explicitly states this: Note that a function that has pointer arguments and examines the data pointed to must not be declared const. Adjust the annotations on this family of functions. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315741 91177308-0d34-0410-b5e6-96231b3b80d8
…modeled. The checker used to crash when a mempcpy's length argument is symbolic. In this case the cast from 'void *' to 'char *' failed because the respective ElementRegion that represents cast is hard to add on top of the existing ElementRegion that represents the offset to the last copied byte, while preseving a sane memory region structure. Additionally, a few test cases are added (to casts.c) which demonstrate problems caused by existing sloppy work we do with multi-layer ElementRegions. If said cast would be modeled properly in the future, these tests would need to be taken into account. Differential Revision: https://reviews.llvm.org/D38797 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315742 91177308-0d34-0410-b5e6-96231b3b80d8
In some cases the analyzer didn't expect an array-type variable to be initialized with anything other than a string literal. The patch essentially removes the assertion, and ensures relatively sane behavior. There is a bigger problem with these initializers. Currently our memory model (RegionStore) is being ordered to initialize the array with a region that is assumed to be storing the initializer rvalue, and it guesses to copy the contents of that region to the array variable. However, it would make more sense for RegionStore to receive the correct initializer in the first place. This problem isn't addressed with this patch. rdar://problem/27248428 Differential Revision: https://reviews.llvm.org/D23963 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315750 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315755 91177308-0d34-0410-b5e6-96231b3b80d8
When LLVM_BUILD_EXTERNAL_COMPILER_RT option is set to true, all of projects in compiler-rt are built with a freshly-built compiler using a recursive CMake invocation. (e.g. that's how compiler-rt is used in Swift) Just now I have noticed that libFuzzer binaries were missing in such a case, and ninja fuzzer returned "no such target", while ninja asan worked just fine. To my surprise, the list of allowed targets was actually hardcoded in Clang! While the current setup is clearly suboptimal, for the lack of a better fix I'm just adding `fuzzer` to a list of `compiler-rt` targets. Differential Revision: https://reviews.llvm.org/D38904 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315771 91177308-0d34-0410-b5e6-96231b3b80d8
It's possible for the code completion consumer to add new decls to the current scope while lookup happens on it. Avoid this by making a copy first. Sadly I wasn't able to get a self-contained test case for this as it requires code completion + precompiled preamble + the stars aligning to deserialize at exactly the right time. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315772 91177308-0d34-0410-b5e6-96231b3b80d8
The ParsedSourceRange class does not work correctly on Windows with the ':' drive separators git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315774 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315776 91177308-0d34-0410-b5e6-96231b3b80d8
…numerators feature. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315784 91177308-0d34-0410-b5e6-96231b3b80d8
Credit to OSS-Fuzz for discovery: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3145 rdar://34526482 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315785 91177308-0d34-0410-b5e6-96231b3b80d8
The function sanitizer only checks indirect calls through function pointers. This excludes all non-static member functions (constructor calls, calls through thunks, etc. all use a separate code path). Don't emit function signatures for functions that won't be checked. Apart from cutting down on code size, this should fix a regression on Linux caused by r313096. For context, see the mailing list discussion: r313096 - [ubsan] Function Sanitizer: Don't require writable text segments Testing: check-clang, check-ubsan Differential Revision: https://reviews.llvm.org/D38913 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315786 91177308-0d34-0410-b5e6-96231b3b80d8
…itializer. If the variable construction can be constant evaluated it doesn't have side effects, so removing it is always safe. We only try to evaluate variables that are unused, there should be no impact on compile time. Differential Revision: https://reviews.llvm.org/D38678 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315787 91177308-0d34-0410-b5e6-96231b3b80d8
In OpenCL the kernel function and non-kernel function has different calling conventions. For certain targets they have different argument ABIs. Also kernels have special function attributes and metadata for runtime to launch them. The blocks passed to enqueue_kernel is supposed to be executed as kernels. As such, the block invoke function should be emitted as kernel with proper calling convention and argument ABI. This patch emits enqueued block as kernel. If a block is both called directly and passed to enqueue_kernel, separate functions will be generated. Differential Revision: https://reviews.llvm.org/D38134 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315804 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315805 91177308-0d34-0410-b5e6-96231b3b80d8
…nt evaluate the initializer." check-libcxx dislikes it. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315806 91177308-0d34-0410-b5e6-96231b3b80d8
…nt evaluate the initializer." The warnings in libc++ tests were fixed in the meantime. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315811 91177308-0d34-0410-b5e6-96231b3b80d8
This is causing: http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/43381 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315829 91177308-0d34-0410-b5e6-96231b3b80d8
Test is fixed in r315830 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315831 91177308-0d34-0410-b5e6-96231b3b80d8
This patch implements an extension to the preprocessor: __VA_OPT__(contents) --> which expands into its contents if variadic arguments are supplied to the parent macro, or behaves as an empty token if none. - Currently this feature is only enabled for C++2a (this could be enabled, with some careful tweaks, for other dialects with the appropriate extension or compatibility warnings) - The patch was reviewed here: https://reviews.llvm.org/D35782 and asides from the above (and moving some of the definition and expansion recognition logic into the corresponding state machines), I believe I incorporated all of Richard's suggestions. A few technicalities (most of which were clarified through private correspondence between rsmith, hubert and thomas) are worth mentioning. Given: #define F(a,...) a #__VA_OPT__(a ## a) a ## __VA_OPT__(__VA_ARGS__) - The call F(,) Does not supply any tokens for the variadic arguments and hence VA_OPT behaves as a placeholder. - When expanding VA_OPT (for e.g. F(,1) token pasting occurs eagerly within its contents if the contents need to be stringified. - A hash or a hashhash prior to VA_OPT does not inhibit expansion of arguments if they are the first token within VA_OPT. - When a variadic argument is supplied, argument substitution occurs within the contents as does stringification - and these resulting tokens are inserted back into the macro expansions token stream just prior to the entire stream being rescanned and concatenated. See wg21.link/P0306 for further details on the feature. Acknowledgment: This patch would have been poorer if not for Richard Smith's usual thoughtful analysis and feedback. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315840 91177308-0d34-0410-b5e6-96231b3b80d8
…on warning to a diagnostic group (in r315840) In passing also complete a comment that I left uncompleted. For ease of reference, here's the parent commit: https://reviews.llvm.org/rL315840 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315842 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315845 91177308-0d34-0410-b5e6-96231b3b80d8
…control use of [[]] attributes in all language modes. This is the initial implementation of WG14 N2165, which is a proposal to add [[]] attributes to C2x, but also allows you to enable these attributes in C++98, or disable them in C++11 or later. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315856 91177308-0d34-0410-b5e6-96231b3b80d8
Patch by: daxpedda Differential Revision: https://reviews.llvm.org/D38123 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315864 91177308-0d34-0410-b5e6-96231b3b80d8
When using lld on macOS the current level of detection between ld and ld64 forces us to rename lld to ld. For ELF targets we have the ld.lld alias so for MACHO we should have ld64.lld so we can use lld without replacing the system compiler. This also solves the additional issue of cross compiling for MACHO where renaming lld to ld with only target ELF. This is the clang driver component change to use this new alias. Reviewers: ruiu, rnk Differential Revision: https://reviews.llvm.org/D38290 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315867 91177308-0d34-0410-b5e6-96231b3b80d8
The patch should have been checking against STDCXX17 not STDCXX14. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315868 91177308-0d34-0410-b5e6-96231b3b80d8
Replace MSP430 with LEG, plus add the wire up in clang.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a clang part of October 2017 bump.
It brings
clangLEGto 15 October 2017: aba0729dd1.As per llvm PR I discarded the original commits, made by @frasercrmck and @pasaulais and only took the actual changes that they introduced.