Commit Graph

546 Commits

Author SHA1 Message Date
Alexey Bataev 2f7269b677 Fix compiler crash when an expression parsed in the tentative parsing and must be claimed in the another evaluation context.
Summary:
Clang crashes when trying to finish function body. MaybeODRUseExprs is
not empty because of const static data member parsed in outer evaluation
context, upon call for isTypeIdInParens() function. It builds
annot_primary_expr, later parsed in ParseConstantExpression() in
inner constant expression evaluation context.

Reviewers: rjmccall, rsmith

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D80925
2020-06-02 14:27:33 -04:00
Anastasia Stulova a6a237f204 [OpenCL] Added addrspace_cast operator in C++ mode.
This operator is intended for casting between
pointers to objects in different address spaces
and follows similar logic as const_cast in C++.

Tags: #clang

Differential Revision: https://reviews.llvm.org/D60193
2020-05-18 12:07:54 +01:00
Erich Keane 5f0903e9be Reland Implement _ExtInt as an extended int type specifier.
I fixed the LLDB issue, so re-applying the patch.

This reverts commit a4b88c0449.
2020-04-17 10:45:48 -07:00
Sterling Augustine a4b88c0449 Revert "Implement _ExtInt as an extended int type specifier."
This reverts commit 61ba1481e2.

I'm reverting this because it breaks the lldb build with
incomplete switch coverage warnings. I would fix it forward,
but am not familiar enough with lldb to determine the correct
fix.

lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:3958:11: error: enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch [-Werror,-Wswitch]
  switch (qual_type->getTypeClass()) {
          ^
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:4633:11: error: enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch [-Werror,-Wswitch]
  switch (qual_type->getTypeClass()) {
          ^
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:4889:11: error: enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch [-Werror,-Wswitch]
  switch (qual_type->getTypeClass()) {
2020-04-17 10:29:40 -07:00
Erich Keane 61ba1481e2 Implement _ExtInt as an extended int type specifier.
Introduction/Motivation:
LLVM-IR supports integers of non-power-of-2 bitwidth, in the iN syntax.
Integers of non-power-of-two aren't particularly interesting or useful
on most hardware, so much so that no language in Clang has been
motivated to expose it before.

However, in the case of FPGA hardware normal integer types where the
full bitwidth isn't used, is extremely wasteful and has severe
performance/space concerns.  Because of this, Intel has introduced this
functionality in the High Level Synthesis compiler[0]
under the name "Arbitrary Precision Integer" (ap_int for short). This
has been extremely useful and effective for our users, permitting them
to optimize their storage and operation space on an architecture where
both can be extremely expensive.

We are proposing upstreaming a more palatable version of this to the
community, in the form of this proposal and accompanying patch.  We are
proposing the syntax _ExtInt(N).  We intend to propose this to the WG14
committee[1], and the underscore-capital seems like the active direction
for a WG14 paper's acceptance.  An alternative that Richard Smith
suggested on the initial review was __int(N), however we believe that
is much less acceptable by WG14.  We considered _Int, however _Int is
used as an identifier in libstdc++ and there is no good way to fall
back to an identifier (since _Int(5) is indistinguishable from an
unnamed initializer of a template type named _Int).

[0]https://www.intel.com/content/www/us/en/software/programmable/quartus-prime/hls-compiler.html)
[1]http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2472.pdf

Differential Revision: https://reviews.llvm.org/D73967
2020-04-17 07:10:57 -07:00
Kadir Cetinkaya 0731132888
[clang][CodeComplete] Dont perform fallback completion for incomplete member ref
Summary:
Clang performs expression based completion whenever it can't figure out
base of a member reference expression. It might be quite confusing in cases like
incomplete types. This patch disables that fallback.

Unfortunately `ParsePostfixExpressionSuffix` is quite tangled and this patch
adds more to it.

Reviewers: sammccall

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D77570
2020-04-06 20:08:24 +02:00
Alexey Bataev 9b3bf72a0d [OPENMP50]Allow use of array shaping expression in a list.
Need to allow arrayshaping expression in a list of expressions, so use
ParseAssignmentExpression() when try to parse the base of the shaping
operation.
2020-03-31 17:15:31 -04:00
Richard Smith 3308732300 Fix crash if base specifier parsing hits an invalid type annotation.
Also change type annotation representation from ParsedType to TypeResult
to make it clearer to consumers that they can represent invalid types.
2020-03-30 17:21:40 -07:00
Alexey Bataev 7ac9efb0c3 [OPENMP50]Add basic support for array-shaping operation.
Summary:
Added basic representation and parsing/sema handling of array-shaping
operations. Array shaping expression is an expression of form ([s0]..[sn])base,
where s0, ..., sn must be a positive integer, base - a pointer. This
expression is a kind of cast operation that converts pointer expression
into an array-like kind of expression.

Reviewers: rjmccall, rsmith, jdoerfert

Subscribers: guansong, arphaman, cfe-commits, caomhin, kkwli0

Tags: #clang

Differential Revision: https://reviews.llvm.org/D74144
2020-03-30 09:18:24 -04:00
Haojian Wu a9ab11d408 [AST] Build recovery expressions for nonexistent member exprs.
Summary: Previously, we dropped the AST node for nonexistent member exprs.

Reviewers: sammccall

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D76764
2020-03-26 08:50:33 +01:00
Erich Keane b5a034e771 [SYCL] Implement __builtin_unique_stable_name.
In order to support non-user-named kernels, SYCL needs some way in the
integration headers to name the kernel object themselves. Initially, the
design considered just RTTI naming of the lambdas, this results in a
quite unstable situation in light of some device/host macros.
Additionally, this ends up needing to use RTTI, which is a burden on the
implementation and typically unsupported.

Instead, we've introduced a builtin, __builtin_unique_stable_name, which
takes a type or expression, and results in a constexpr constant
character array that uniquely represents the type (or type of the
expression) being passed to it.

The implementation accomplishes that simply by using a slightly modified
version of the Itanium Mangling. The one exception is when mangling
lambdas, instead of appending the index of the lambda in the function,
it appends the macro-expansion back-trace of the lambda itself in the
form LINE->COL[~LINE->COL...].

Differential Revision: https://reviews.llvm.org/D76620
2020-03-25 07:01:50 -07:00
Haojian Wu 733edf9750 [AST] Add RecoveryExpr to retain expressions on semantic errors
Normally clang avoids creating expressions when it encounters semantic
errors, even if the parser knows which expression to produce.

This works well for the compiler. However, this is not ideal for
source-level tools that have to deal with broken code, e.g. clangd is
not able to provide navigation features even for names that compiler
knows how to resolve.

The new RecoveryExpr aims to capture the minimal set of information
useful for the tools that need to deal with incorrect code:

source range of the expression being dropped,
subexpressions of the expression.
We aim to make constructing RecoveryExprs as simple as possible to
ensure writing code to avoid dropping expressions is easy.

Producing RecoveryExprs can result in new code paths being taken in the
frontend. In particular, clang can produce some new diagnostics now and
we aim to suppress bogus ones based on Expr::containsErrors.

We deliberately produce RecoveryExprs only in the parser for now to
minimize the code affected by this patch. Producing RecoveryExprs in
Sema potentially allows to preserve more information (e.g. type of an
expression), but also results in more code being affected. E.g.
SFINAE checks will have to take presence of RecoveryExprs into account.

Initial implementation only works in C++ mode, as it relies on compiler
postponing diagnostics on dependent expressions. C and ObjC often do not
do this, so they require more work to make sure we do not produce too
many bogus diagnostics on the new expressions.

See documentation of RecoveryExpr for more details.

original patch from Ilya
This change is based on https://reviews.llvm.org/D61722

Reviewers: sammccall, rsmith

Reviewed By: sammccall, rsmith

Tags: #clang

Differential Revision: https://reviews.llvm.org/D69330
2020-03-24 09:20:37 +01:00
Haojian Wu 0dd0b1017c [Parser] Avoid spurious 'missing template' error in presence of typos.
Suppress those diagnostics if lhs of a member expression contains
errors. Typo correction produces dependent expressions even in
non-template code, that led to spurious diagnostics before.

previous:
    /tmp/t.cpp:6:17: error: use 'template' keyword to treat 'f' as a dependent template name
    auto a = bilder.f<int>();
                    ^
                    template
    /tmp/t.cpp:6:10: error: use of undeclared identifier 'bilder'; did you mean 'builder'?
    auto a = bilder.f<int>();
             ^~~~~~
             builder

vs now:

    /tmp/t.cpp:6:10: error: use of undeclared identifier 'bilder'; did you mean 'builder'?
    auto a = bilder.f<int>();
             ^~~~~~
             builder

Original patch from Ilya.

Reviewers: sammccall

Reviewed By: sammccall

Tags: #clang

Differential Revision: https://reviews.llvm.org/D65592
2020-03-19 16:15:27 +01:00
Richard Smith 5c845c1c50 PR45083: Mark statement expressions as being dependent if they appear in
a dependent context.

This matches the GCC behavior.

We track the enclosing template depth when determining whether a
statement expression is within a dependent context; there doesn't appear
to be any other reliable way to determine this.

We previously assumed they were neither value- nor
instantiation-dependent under any circumstances, which would lead to
crashes and other misbehavior.
2020-03-10 14:45:04 -07:00
Benjamin Kramer 66addf8e80 Revert "Fix regression in bdad0a1: force rebuilding of StmtExpr nodes in", "PR45083: Mark statement expressions as being dependent if they appear in"
This reverts commit f545ede91c.
This reverts commit bdad0a1b79.

This crashes clang. I'll follow up with reproduction instructions.
2020-03-05 14:14:31 +01:00
Richard Smith bdad0a1b79 PR45083: Mark statement expressions as being dependent if they appear in
dependent contexts.

We previously assumed they were neither value- nor
instantiation-dependent under any circumstances, which would lead to
crashes and other misbehavior.
2020-03-03 15:20:40 -08:00
Jim Lin 466f8843f5 [NFC] Remove trailing space
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h,td}
2020-02-18 10:49:13 +08:00
Saar Raz 73eaf62463 [Concepts] Make constraint expressions unevaluated until satisfaction checking
As per P1980R0, constraint expressions are unevaluated operands, and their constituent atomic
constraints only become constant evaluated during satisfaction checking.

Change the evaluation context during parsing and instantiation of constraints to unevaluated.
2020-01-24 02:24:21 +02:00
Kadir Cetinkaya 24364cd12b
[clang][CodeComplete] Make completion work after initializer lists
Summary:
CodeCompletion was not being triggered after successfully parsed
initializer lists, e.g.

```cpp
void foo(int, bool);
void bar() {
  foo({1}^, false);
}
```

CodeCompletion would suggest the function foo as an overload candidate up until
the point marked with `^` but after that point we do not trigger signature help
since parsing succeeds.

This patch handles that case by failing in parsing expression lists whenever we
see a codecompletion token, in addition to getting an invalid subexpression.

Reviewers: sammccall

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D73177
2020-01-23 15:32:46 +01:00
Saar Raz a0f50d7316 [Concepts] Requires Expressions
Implement support for C++2a requires-expressions.

Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair.

Differential Revision: https://reviews.llvm.org/D50360
2020-01-19 00:23:26 +02:00
Saar Raz baa84d8cde Revert "[Concepts] Requires Expressions"
This reverts commit 0279318997.

There have been some failing tests on some platforms, reverting while investigating.
2020-01-18 14:58:01 +02:00
Saar Raz 0279318997 [Concepts] Requires Expressions
Implement support for C++2a requires-expressions.

Differential Revision: https://reviews.llvm.org/D50360
2020-01-18 09:15:36 +02:00
Richard Smith a42fd84cff Remove redundant CXXScopeSpec from TemplateIdAnnotation.
A TemplateIdAnnotation represents only a template-id, not a
nested-name-specifier plus a template-id. Don't make a redundant copy of
the CXXScopeSpec and store it on the template-id annotation.

This slightly improves error recovery by more properly handling the case
where we would form an invalid CXXScopeSpec while parsing a typename
specifier, instead of accidentally putting the token stream into a
broken "annot_template_id with a scope specifier, but with no preceding
annot_cxxscope token" state.
2020-01-17 15:47:21 -08:00
Simon Pilgrim f3849f739e Fix Wdocumentation warning. NFCI. 2020-01-10 10:32:37 +00:00
Saar Raz b65b1f322b [Concepts] Function trailing requires clauses
Function trailing requires clauses now parsed, supported in overload resolution and when calling, referencing and taking the address of functions or function templates.

Differential Revision: https://reviews.llvm.org/D43357
2020-01-09 15:07:51 +02:00
Saar Raz 5d98ba6077 [Concepts] Concept Specialization Expressions
Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is refe$

D41217 on Phabricator.

(recommit after fixing failing Parser test on windows)

llvm-svn: 374903
2019-10-15 15:24:26 +00:00
Nico Weber b4638f9ff0 Revert 374882 "[Concepts] Concept Specialization Expressions"
This reverts commit ec87b00382.
The test fails on Windows, see e.g.
http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/11533/steps/stage%201%20check/logs/stdio

Also revert follow-up r374893.

llvm-svn: 374899
2019-10-15 14:46:39 +00:00
Saar Raz ec87b00382 [Concepts] Concept Specialization Expressions
Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is referenced with arguments, and tests thereof.

llvm-svn: 374882
2019-10-15 11:48:58 +00:00
Richard Smith 7e8fe67f0e PR43080: Do not build context-sensitive expressions during name classification.
Summary:
We don't know what context to use until the classification result is
consumed by the parser, which could happen in a different semantic
context. So don't build the expression that results from name
classification until we get to that point and can handle it properly.

This covers everything except C++ implicit class member access, which
is a little awkward to handle properly in the face of the protected
member access check. But it at least fixes all the currently-filed
instances of PR43080.

Reviewers: efriedma

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D68896

llvm-svn: 374826
2019-10-14 21:53:03 +00:00
Aaron Ballman 1d93522056 Replace some custom C11 extension warnings with the generic warning.
llvm-svn: 370066
2019-08-27 14:41:39 +00:00
Aaron Ballman 774bd6ef1c Diagnose use of _Thread_local as an extension when not in C11 mode.
llvm-svn: 369954
2019-08-26 19:44:07 +00:00
Richard Smith 2e3ed4a852 Stop abusing SuppressAllDiagnostics when speculatively determining
whether an expression would be valid during error recovery.

llvm-svn: 369145
2019-08-16 19:53:22 +00:00
Jonas Devlieghere 2b3d49b610 [Clang] Migrate llvm::make_unique to std::make_unique
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

Differential revision: https://reviews.llvm.org/D66259

llvm-svn: 368942
2019-08-14 23:04:18 +00:00
Rui Ueyama 49a3ad21d6 Fix parameter name comments using clang-tidy. NFC.
This patch applies clang-tidy's bugprone-argument-comment tool
to LLVM, clang and lld source trees. Here is how I created this
patch:

$ git clone https://github.com/llvm/llvm-project.git
$ cd llvm-project
$ mkdir build
$ cd build
$ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \
    -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \
    -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \
    -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm
$ ninja
$ parallel clang-tidy -checks='-*,bugprone-argument-comment' \
    -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \
    ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h}

llvm-svn: 366177
2019-07-16 04:46:31 +00:00
Erik Pilkington eee944e7f9 [C++2a] Add __builtin_bit_cast, used to implement std::bit_cast
This commit adds a new builtin, __builtin_bit_cast(T, v), which performs a
bit_cast from a value v to a type T. This expression can be evaluated at
compile time under specific circumstances.

The compile time evaluation currently doesn't support bit-fields, but I'm
planning on fixing this in a follow up (some of the logic for figuring this out
is in CodeGen). I'm also planning follow-ups for supporting some more esoteric
types that the constexpr evaluator supports, as well as extending
__builtin_memcpy constexpr evaluation to use the same infrastructure.

rdar://44987528

Differential revision: https://reviews.llvm.org/D62825

llvm-svn: 364954
2019-07-02 18:28:13 +00:00
Ilya Biryukov 929af67361 [Lex] Allow to consume tokens while preprocessing
Summary:
By adding a hook to consume all tokens produced by the preprocessor.
The intention of this change is to make it possible to consume the
expanded tokens without re-runnig the preprocessor with minimal changes
to the preprocessor and minimal performance penalty when preprocessing
without recording the tokens.

The added hook is very low-level and reconstructing the expanded token
stream requires more work in the client code, the actual algorithm to
collect the tokens using this hook can be found in the follow-up change.

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: eraman, nemanjai, kbarton, jsji, riccibruno, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D59885

llvm-svn: 361007
2019-05-17 09:32:05 +00:00
Eric Fiselier 708afb56c1 Implement __builtin_LINE() et. al. to support source location capture.
Summary:
This patch implements the source location builtins `__builtin_LINE(), `__builtin_FUNCTION()`, `__builtin_FILE()` and `__builtin_COLUMN()`. These builtins are needed to implement [`std::experimental::source_location`](https://rawgit.com/cplusplus/fundamentals-ts/v2/main.html#reflection.src_loc.creation).

With the exception of `__builtin_COLUMN`, GCC also implements these builtins, and Clangs behavior is intended to match as closely as possible. 

Reviewers: rsmith, joerg, aaron.ballman, bogner, majnemer, shafik, martong

Reviewed By: rsmith

Subscribers: rnkovacs, loskutov, riccibruno, mgorny, kunitoki, alexr, majnemer, hfinkel, cfe-commits

Differential Revision: https://reviews.llvm.org/D37035

llvm-svn: 360937
2019-05-16 21:04:15 +00:00
Volodymyr Sapsai 31f7c4aa77 [Parser] Avoid correcting delayed typos in array subscript multiple times.
We correct some typos in `ActOnArraySubscriptExpr` and
`ActOnOMPArraySectionExpr`, so when their result is `ExprError`, we can
end up correcting delayed typos in the same expressions again. In
general it is OK but when `NumTypos` is incorrect, we can hit the
assertion

> Assertion failed: (Entry != DelayedTypos.end() && "Failed to get the state for a TypoExpr!"), function getTypoExprState, file clang/lib/Sema/SemaLookup.cpp, line 5219.

Fix by replacing some subscript `ExprResult` with typo-corrected expressions
instead of keeping the original expressions. Thus if original expressions
contained `TypoExpr`, we'll use corrected expressions instead of trying to
correct them again.

rdar://problem/47403222

Reviewers: rsmith, erik.pilkington, majnemer

Reviewed By: erik.pilkington

Subscribers: jkorous, dexonsmith, cfe-commits

Differential Revision: https://reviews.llvm.org/D60848

llvm-svn: 359713
2019-05-01 19:24:50 +00:00
Bruno Ricci 70ad396bc4 [Sema][NFCI] Don't allocate storage for the various CorrectionCandidateCallback unless we are going to do some typo correction
The various CorrectionCandidateCallbacks are currently heap-allocated
unconditionally. This was needed because of delayed typo correction.
However these allocations represent currently 15.4% of all allocations
(number of allocations) when parsing all of Boost (!), mostly because
of ParseCastExpression, ParseStatementOrDeclarationAfterAttrtibutes
and isCXXDeclarationSpecifier. Note that all of these callback objects
are small. Let's not do this.

Instead initially allocate the callback on the stack, and only do a
heap allocation if we are going to do some typo correction. Do this by:

1. Adding a clone function to each callback, which will do a polymorphic
   clone of the callback. This clone function is required to be implemented
   by every callback (of which there is a fair amount). Make sure this is
   the case by making it pure virtual.

2. Use this clone function when we are going to try to correct a typo.

This additionally cut the time of -fsyntax-only on all of Boost by 0.5%
(not that much, but still something). No functional changes intended.

Differential Revision: https://reviews.llvm.org/D58827

Reviewed By: rnk

llvm-svn: 356925
2019-03-25 17:08:51 +00:00
Ilya Biryukov ff2a99752f [CodeComplete] Propagate preferred type for function arguments in more cases
Summary:
See the added test for some new cases.
This change also removes special code completion calls inside the
ParseExpressionList function now that we properly propagate expected
type to the function responsible for parsing elements of the expression list
(ParseAssignmentExpression).

Reviewers: kadircet

Reviewed By: kadircet

Subscribers: xbolva00, jdoerfert, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D58541

llvm-svn: 354864
2019-02-26 11:01:50 +00:00
Ilya Biryukov 4f9543b4d6 [CodeComplete] Propagate preferred types through parser in more cases
Preferred types are used by code completion for ranking. This commit
considerably increases the number of points in code where those types
are propagated.

In order to avoid complicating signatures of Parser's methods, a
preferred type is kept as a member variable in the parser and updated
during parsing.

Differential revision: https://reviews.llvm.org/D56723

llvm-svn: 352788
2019-01-31 20:20:32 +00:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
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
2019-01-19 08:50:56 +00:00
Anastasia Stulova a9bc4bd814 Use DeclSpec for quals in DeclaratorChunk::FunctionTypeInfo.
Rather than duplicating data fields, use DeclSpec directly to store
the qualifiers for the functions/methods. This change doesn't handle
attributes yet and has to be extended further.

Differential revision: https://reviews.llvm.org/D55948

llvm-svn: 350703
2019-01-09 11:25:09 +00:00
Ilya Biryukov 4974d75d7c [CodeComplete] Fill preferred type on binary expressions
Reviewers: kadircet

Reviewed By: kadircet

Subscribers: arphaman, cfe-commits

Differential Revision: https://reviews.llvm.org/D55648

llvm-svn: 349053
2018-12-13 16:06:11 +00:00
Reid Kleckner 4dc0b1ac60 Fix clang -Wimplicit-fallthrough warnings across llvm, NFC
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
2018-11-01 19:54:45 +00:00
Erik Pilkington fa98390b3c NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)
We haven't supported compiling ObjC1 for a long time (and never will again), so
there isn't any reason to keep these separate. This patch replaces
LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC.

Differential revision: https://reviews.llvm.org/D53547

llvm-svn: 345637
2018-10-30 20:31:30 +00:00
Richard Smith 6822bd79ac PR26547: alignof should return ABI alignment, not preferred alignment
Summary:
- Add `UETT_PreferredAlignOf` to account for the difference between `__alignof` and `alignof`
- `AlignOfType` now returns ABI alignment instead of preferred alignment iff clang-abi-compat > 7, and one uses _Alignof or alignof

Patch by Nicole Mazzuca!

Differential Revision: https://reviews.llvm.org/D53207

llvm-svn: 345419
2018-10-26 19:26:45 +00:00
Will Wilson caa02f879f [ms] Prevent explicit constructor name lookup if scope is missing
MicrosoftExt allows explicit constructor calls. Prevent lookup of constructor name unless the name has explicit scope.
This avoids a compile-time crash due to confusing a member access for a constructor name.

Test case included. All tests pass.

Differential Revision: https://reviews.llvm.org/D53441

llvm-svn: 345258
2018-10-25 11:45:32 +00:00
Ivan Donchevskii 60a16ef04b [CodeComplete] Generate completion fix-its for C code as well
Current completion fix-its approach does not provide OtherOpBase for C code.
But we can easily proceed in this case taking the original Base type.

Differential Revision: https://reviews.llvm.org/D52261

llvm-svn: 342721
2018-09-21 11:23:22 +00:00
Kadir Cetinkaya a32d253f10 [clang] Make sure codecompletion is called for calls even when inside a token.
Summary:
Currently CodeCompleteCall only gets called after a comma or parantheses. This
patch makes sure it is called even at the cases like:
```foo(1^);```

Reviewers: ilya-biryukov, ioeric, hokein

Reviewed By: ilya-biryukov

Subscribers: MaskRay, jkorous, arphaman, cfe-commits

Differential Revision: https://reviews.llvm.org/D51038

llvm-svn: 341824
2018-09-10 13:46:28 +00:00