maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/lib/Sema/Scope.cpp

225 lines
6.9 KiB
C++
Raw Normal View History

Store a parameter index and function prototype depth in every parameter node and use this to correctly mangle parameter references in function template signatures. A follow-up patch will improve the storage usage of these fields; here I've just done the lazy thing. llvm-svn: 130669
2011-05-02 06:35:37 +08:00
//===- Scope.cpp - Lexical scope information --------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This file implements the Scope class, which is used for recording
// information about a lexical scope.
//
//===----------------------------------------------------------------------===//
#include "clang/Sema/Scope.h"
Rewrite NRVO determination. Track NRVO candidates on the parser Scope and apply the NRVO candidate flag to all possible NRVO candidates here, and remove the flags in computeNRVO or upon template instantiation. A variable now has NRVO applied if and only if every return statement in that scope returns that variable. This is nearly optimal. Performs NRVO roughly 7% more often in a bootstrap build of clang. Patch co-authored by Richard Smith. llvm-svn: 207890
2014-05-03 08:41:18 +08:00
#include "clang/AST/Decl.h"
[-cxx-abi microsoft] Implement local manglings accurately Summary: The MSVC ABI appears to mangle the lexical scope into the names of statics. Specifically, a counter is incremented whenever a scope is entered where things can be declared in such a way that an ambiguity can arise. For example, a class scope inside of a class scope doesn't do anything interesting because the nested class cannot collide with another nested class. There are problems with this scheme: - It is unreliable. The counter is only incremented when a previously never encountered scope is entered. There are cases where this will cause ambiguity amongst declarations that have the same name where one was introduced in a deep scope while the other was introduced right after in the previous lexical scope. - It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}} will make the mangling of "foo" larger than it need be because the scope counter has been incremented many times. Because of these problems, and practical implementation concerns. We choose not to implement this scheme if the local static or local type isn't visible. The mangling of these declarations will look very similar but the numbering will make far more sense, this scheme is lifted from the Itanium ABI implementation. Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2953 llvm-svn: 202951
2014-03-05 16:57:59 +08:00
#include "llvm/Support/raw_ostream.h"
Store a parameter index and function prototype depth in every parameter node and use this to correctly mangle parameter references in function template signatures. A follow-up patch will improve the storage usage of these fields; here I've just done the lazy thing. llvm-svn: 130669
2011-05-02 06:35:37 +08:00
using namespace clang;
void Scope::Init(Scope *parent, unsigned flags) {
AnyParent = parent;
Flags = flags;
Reject continue/break statements within members of local functions nested within loop and switch statements, by teaching Scope that a function scope never has a continue/break parent for the purposes of control flow. Remove the hack in block and lambda expressions which worked around this by pretending that such expressions were continue/break scopes. Remove Scope::ControlParent, since it's unused. In passing, teach default statements to recover properly from a missing ';', and add a fixit for same to both default and case labels (the latter already recovered correctly). llvm-svn: 150776
2012-02-17 09:35:32 +08:00
if (parent && !(flags & FnScope)) {
BreakParent = parent->BreakParent;
ContinueParent = parent->ContinueParent;
} else {
// Control scopes do not contain the contents of nested function scopes for
// control flow purposes.
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
BreakParent = ContinueParent = nullptr;
Reject continue/break statements within members of local functions nested within loop and switch statements, by teaching Scope that a function scope never has a continue/break parent for the purposes of control flow. Remove the hack in block and lambda expressions which worked around this by pretending that such expressions were continue/break scopes. Remove Scope::ControlParent, since it's unused. In passing, teach default statements to recover properly from a missing ';', and add a fixit for same to both default and case labels (the latter already recovered correctly). llvm-svn: 150776
2012-02-17 09:35:32 +08:00
}
Store a parameter index and function prototype depth in every parameter node and use this to correctly mangle parameter references in function template signatures. A follow-up patch will improve the storage usage of these fields; here I've just done the lazy thing. llvm-svn: 130669
2011-05-02 06:35:37 +08:00
if (parent) {
Depth = parent->Depth + 1;
PrototypeDepth = parent->PrototypeDepth;
PrototypeIndex = 0;
FnParent = parent->FnParent;
BlockParent = parent->BlockParent;
TemplateParamParent = parent->TemplateParamParent;
MS ABI: Implement the MSVC 2015 scheme for scope disambiguation consider C++ that looks like: inline int &f(bool b) { if (b) { static int i; return i; } static int i; return i; } Both 'i' variables must have distinct (and stable) names for linkage purposes. The MSVC 2013 ABI would number the variables using a count of the number of scopes that have been created. However, the final 'i' returns to a scope that has already been created leading to a mangling collision. MSVC 2015 fixes this by giving the second 'i' the name it would have if it were declared before the 'if'. However, this results in ABI breakage because the mangled name, in cases where there was no ambiguity, would now be different. We implement the new behavior and only enable it if we are targeting the MSVC 2015 ABI, otherwise the old behavior will be used. This fixes PR18131. llvm-svn: 232766
2015-03-20 05:54:30 +08:00
MSLastManglingParent = parent->MSLastManglingParent;
MSCurManglingNumber = getMSLastManglingNumber();
[OPENMP] Loop canonical form analysis (Sema) This patch implements semantic analysis to make sure that the loop is in OpenMP canonical form. This is the form required for 'omp simd', 'omp for' and other loop pragmas. Differential revision: http://reviews.llvm.org/D3778 llvm-svn: 210095
2014-06-03 18:16:47 +08:00
if ((Flags & (FnScope | ClassScope | BlockScope | TemplateParamScope |
FunctionPrototypeScope | AtCatchScope | ObjCMethodScope)) ==
0)
Flags |= parent->getFlags() & OpenMPSimdDirectiveScope;
Store a parameter index and function prototype depth in every parameter node and use this to correctly mangle parameter references in function template signatures. A follow-up patch will improve the storage usage of these fields; here I've just done the lazy thing. llvm-svn: 130669
2011-05-02 06:35:37 +08:00
} else {
Depth = 0;
PrototypeDepth = 0;
PrototypeIndex = 0;
MS ABI: Implement the MSVC 2015 scheme for scope disambiguation consider C++ that looks like: inline int &f(bool b) { if (b) { static int i; return i; } static int i; return i; } Both 'i' variables must have distinct (and stable) names for linkage purposes. The MSVC 2013 ABI would number the variables using a count of the number of scopes that have been created. However, the final 'i' returns to a scope that has already been created leading to a mangling collision. MSVC 2015 fixes this by giving the second 'i' the name it would have if it were declared before the 'if'. However, this results in ABI breakage because the mangled name, in cases where there was no ambiguity, would now be different. We implement the new behavior and only enable it if we are targeting the MSVC 2015 ABI, otherwise the old behavior will be used. This fixes PR18131. llvm-svn: 232766
2015-03-20 05:54:30 +08:00
MSLastManglingParent = FnParent = BlockParent = nullptr;
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
TemplateParamParent = nullptr;
MS ABI: Implement the MSVC 2015 scheme for scope disambiguation consider C++ that looks like: inline int &f(bool b) { if (b) { static int i; return i; } static int i; return i; } Both 'i' variables must have distinct (and stable) names for linkage purposes. The MSVC 2013 ABI would number the variables using a count of the number of scopes that have been created. However, the final 'i' returns to a scope that has already been created leading to a mangling collision. MSVC 2015 fixes this by giving the second 'i' the name it would have if it were declared before the 'if'. However, this results in ABI breakage because the mangled name, in cases where there was no ambiguity, would now be different. We implement the new behavior and only enable it if we are targeting the MSVC 2015 ABI, otherwise the old behavior will be used. This fixes PR18131. llvm-svn: 232766
2015-03-20 05:54:30 +08:00
MSLastManglingNumber = 1;
MSCurManglingNumber = 1;
Store a parameter index and function prototype depth in every parameter node and use this to correctly mangle parameter references in function template signatures. A follow-up patch will improve the storage usage of these fields; here I've just done the lazy thing. llvm-svn: 130669
2011-05-02 06:35:37 +08:00
}
// If this scope is a function or contains breaks/continues, remember it.
if (flags & FnScope) FnParent = this;
[-cxx-abi microsoft] Implement local manglings accurately Summary: The MSVC ABI appears to mangle the lexical scope into the names of statics. Specifically, a counter is incremented whenever a scope is entered where things can be declared in such a way that an ambiguity can arise. For example, a class scope inside of a class scope doesn't do anything interesting because the nested class cannot collide with another nested class. There are problems with this scheme: - It is unreliable. The counter is only incremented when a previously never encountered scope is entered. There are cases where this will cause ambiguity amongst declarations that have the same name where one was introduced in a deep scope while the other was introduced right after in the previous lexical scope. - It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}} will make the mangling of "foo" larger than it need be because the scope counter has been incremented many times. Because of these problems, and practical implementation concerns. We choose not to implement this scheme if the local static or local type isn't visible. The mangling of these declarations will look very similar but the numbering will make far more sense, this scheme is lifted from the Itanium ABI implementation. Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2953 llvm-svn: 202951
2014-03-05 16:57:59 +08:00
// The MS mangler uses the number of scopes that can hold declarations as
// part of an external name.
if (Flags & (ClassScope | FnScope)) {
MS ABI: Implement the MSVC 2015 scheme for scope disambiguation consider C++ that looks like: inline int &f(bool b) { if (b) { static int i; return i; } static int i; return i; } Both 'i' variables must have distinct (and stable) names for linkage purposes. The MSVC 2013 ABI would number the variables using a count of the number of scopes that have been created. However, the final 'i' returns to a scope that has already been created leading to a mangling collision. MSVC 2015 fixes this by giving the second 'i' the name it would have if it were declared before the 'if'. However, this results in ABI breakage because the mangled name, in cases where there was no ambiguity, would now be different. We implement the new behavior and only enable it if we are targeting the MSVC 2015 ABI, otherwise the old behavior will be used. This fixes PR18131. llvm-svn: 232766
2015-03-20 05:54:30 +08:00
MSLastManglingNumber = getMSLastManglingNumber();
MSLastManglingParent = this;
MSCurManglingNumber = 1;
[-cxx-abi microsoft] Implement local manglings accurately Summary: The MSVC ABI appears to mangle the lexical scope into the names of statics. Specifically, a counter is incremented whenever a scope is entered where things can be declared in such a way that an ambiguity can arise. For example, a class scope inside of a class scope doesn't do anything interesting because the nested class cannot collide with another nested class. There are problems with this scheme: - It is unreliable. The counter is only incremented when a previously never encountered scope is entered. There are cases where this will cause ambiguity amongst declarations that have the same name where one was introduced in a deep scope while the other was introduced right after in the previous lexical scope. - It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}} will make the mangling of "foo" larger than it need be because the scope counter has been incremented many times. Because of these problems, and practical implementation concerns. We choose not to implement this scheme if the local static or local type isn't visible. The mangling of these declarations will look very similar but the numbering will make far more sense, this scheme is lifted from the Itanium ABI implementation. Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2953 llvm-svn: 202951
2014-03-05 16:57:59 +08:00
}
Store a parameter index and function prototype depth in every parameter node and use this to correctly mangle parameter references in function template signatures. A follow-up patch will improve the storage usage of these fields; here I've just done the lazy thing. llvm-svn: 130669
2011-05-02 06:35:37 +08:00
if (flags & BreakScope) BreakParent = this;
if (flags & ContinueScope) ContinueParent = this;
if (flags & BlockScope) BlockParent = this;
if (flags & TemplateParamScope) TemplateParamParent = this;
// If this is a prototype scope, record that.
if (flags & FunctionPrototypeScope) PrototypeDepth++;
MS static locals mangling: don't count enum scopes We may not have the mangling for static locals vs. enums completely figured out, but at least for my simple test cases, enums should not increment the mangling number. Differential Revision: http://reviews.llvm.org/D4164 llvm-svn: 211078
2014-06-17 08:00:18 +08:00
[-cxx-abi microsoft] Implement local manglings accurately Summary: The MSVC ABI appears to mangle the lexical scope into the names of statics. Specifically, a counter is incremented whenever a scope is entered where things can be declared in such a way that an ambiguity can arise. For example, a class scope inside of a class scope doesn't do anything interesting because the nested class cannot collide with another nested class. There are problems with this scheme: - It is unreliable. The counter is only incremented when a previously never encountered scope is entered. There are cases where this will cause ambiguity amongst declarations that have the same name where one was introduced in a deep scope while the other was introduced right after in the previous lexical scope. - It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}} will make the mangling of "foo" larger than it need be because the scope counter has been incremented many times. Because of these problems, and practical implementation concerns. We choose not to implement this scheme if the local static or local type isn't visible. The mangling of these declarations will look very similar but the numbering will make far more sense, this scheme is lifted from the Itanium ABI implementation. Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2953 llvm-svn: 202951
2014-03-05 16:57:59 +08:00
if (flags & DeclScope) {
if (flags & FunctionPrototypeScope)
; // Prototype scopes are uninteresting.
else if ((flags & ClassScope) && getParent()->isClassScope())
; // Nested class scopes aren't ambiguous.
else if ((flags & ClassScope) && getParent()->getFlags() == DeclScope)
; // Classes inside of namespaces aren't ambiguous.
MS static locals mangling: don't count enum scopes We may not have the mangling for static locals vs. enums completely figured out, but at least for my simple test cases, enums should not increment the mangling number. Differential Revision: http://reviews.llvm.org/D4164 llvm-svn: 211078
2014-06-17 08:00:18 +08:00
else if ((flags & EnumScope))
; // Don't increment for enum scopes.
[-cxx-abi microsoft] Implement local manglings accurately Summary: The MSVC ABI appears to mangle the lexical scope into the names of statics. Specifically, a counter is incremented whenever a scope is entered where things can be declared in such a way that an ambiguity can arise. For example, a class scope inside of a class scope doesn't do anything interesting because the nested class cannot collide with another nested class. There are problems with this scheme: - It is unreliable. The counter is only incremented when a previously never encountered scope is entered. There are cases where this will cause ambiguity amongst declarations that have the same name where one was introduced in a deep scope while the other was introduced right after in the previous lexical scope. - It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}} will make the mangling of "foo" larger than it need be because the scope counter has been incremented many times. Because of these problems, and practical implementation concerns. We choose not to implement this scheme if the local static or local type isn't visible. The mangling of these declarations will look very similar but the numbering will make far more sense, this scheme is lifted from the Itanium ABI implementation. Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2953 llvm-svn: 202951
2014-03-05 16:57:59 +08:00
else
MS ABI: Implement the MSVC 2015 scheme for scope disambiguation consider C++ that looks like: inline int &f(bool b) { if (b) { static int i; return i; } static int i; return i; } Both 'i' variables must have distinct (and stable) names for linkage purposes. The MSVC 2013 ABI would number the variables using a count of the number of scopes that have been created. However, the final 'i' returns to a scope that has already been created leading to a mangling collision. MSVC 2015 fixes this by giving the second 'i' the name it would have if it were declared before the 'if'. However, this results in ABI breakage because the mangled name, in cases where there was no ambiguity, would now be different. We implement the new behavior and only enable it if we are targeting the MSVC 2015 ABI, otherwise the old behavior will be used. This fixes PR18131. llvm-svn: 232766
2015-03-20 05:54:30 +08:00
incrementMSManglingNumber();
[-cxx-abi microsoft] Implement local manglings accurately Summary: The MSVC ABI appears to mangle the lexical scope into the names of statics. Specifically, a counter is incremented whenever a scope is entered where things can be declared in such a way that an ambiguity can arise. For example, a class scope inside of a class scope doesn't do anything interesting because the nested class cannot collide with another nested class. There are problems with this scheme: - It is unreliable. The counter is only incremented when a previously never encountered scope is entered. There are cases where this will cause ambiguity amongst declarations that have the same name where one was introduced in a deep scope while the other was introduced right after in the previous lexical scope. - It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}} will make the mangling of "foo" larger than it need be because the scope counter has been incremented many times. Because of these problems, and practical implementation concerns. We choose not to implement this scheme if the local static or local type isn't visible. The mangling of these declarations will look very similar but the numbering will make far more sense, this scheme is lifted from the Itanium ABI implementation. Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2953 llvm-svn: 202951
2014-03-05 16:57:59 +08:00
}
Store a parameter index and function prototype depth in every parameter node and use this to correctly mangle parameter references in function template signatures. A follow-up patch will improve the storage usage of these fields; here I've just done the lazy thing. llvm-svn: 130669
2011-05-02 06:35:37 +08:00
DeclsInScope.clear();
UsingDirectives.clear();
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
Entity = nullptr;
Store a parameter index and function prototype depth in every parameter node and use this to correctly mangle parameter references in function template signatures. A follow-up patch will improve the storage usage of these fields; here I've just done the lazy thing. llvm-svn: 130669
2011-05-02 06:35:37 +08:00
ErrorTrap.reset();
Rewrite NRVO determination. Track NRVO candidates on the parser Scope and apply the NRVO candidate flag to all possible NRVO candidates here, and remove the flags in computeNRVO or upon template instantiation. A variable now has NRVO applied if and only if every return statement in that scope returns that variable. This is nearly optimal. Performs NRVO roughly 7% more often in a bootstrap build of clang. Patch co-authored by Richard Smith. llvm-svn: 207890
2014-05-03 08:41:18 +08:00
NRVO.setPointerAndInt(nullptr, 0);
Store a parameter index and function prototype depth in every parameter node and use this to correctly mangle parameter references in function template signatures. A follow-up patch will improve the storage usage of these fields; here I've just done the lazy thing. llvm-svn: 130669
2011-05-02 06:35:37 +08:00
}
Reapply r151638 and r151641. The bug that was caught by Apple's internal buildbots was valid and also showed another bug in my implementation. These are now fixed, with regression tests added to catch them both (not Darwin-specific). Original log: ==================== Revert r151638 because it causes assertion hit on PCH creation for Cocoa.h Original log: --------------------- Correctly track tags and enum members defined in the prototype of a function, and ensure they are properly scoped. This fixes code such as: enum e {x, y}; int f(enum {y, x} n) { return 0; } This finally fixes PR5464 and PR5477. --------------------- I also reverted r151641 which was enhancement on top of r151638. ==================== llvm-svn: 151712
2012-02-29 18:24:19 +08:00
bool Scope::containedInPrototypeScope() const {
const Scope *S = this;
while (S) {
if (S->isFunctionPrototypeScope())
return true;
S = S->getParent();
}
return false;
}
Fix to PR8880 (clang dies processing a for loop) Due to statement expressions supported as GCC extension, it is possible to put 'break' or 'continue' into a loop/switch statement but outside its body, for example: for ( ; ({ if (first) { first = 0; continue; } 0; }); ) This code is rejected by GCC if compiled in C mode but is accepted in C++ code. GCC bug 44715 tracks this discrepancy. Clang used code generation that differs from GCC in both modes: only statement of the third expression of 'for' behaves as if it was inside loop body. This change makes code generation more close to GCC, considering 'break' or 'continue' statement in condition and increment expressions of a loop as it was inside the loop body. It also adds error for the cases when 'break'/'continue' appear outside loop due to this syntax. If code generation differ from GCC, warning is issued. Differential Revision: http://llvm-reviews.chandlerc.com/D2518 llvm-svn: 199897
2014-01-23 23:05:00 +08:00
void Scope::AddFlags(unsigned FlagsToSet) {
assert((FlagsToSet & ~(BreakScope | ContinueScope)) == 0 &&
"Unsupported scope flags");
if (FlagsToSet & BreakScope) {
assert((Flags & BreakScope) == 0 && "Already set");
BreakParent = this;
}
if (FlagsToSet & ContinueScope) {
assert((Flags & ContinueScope) == 0 && "Already set");
ContinueParent = this;
}
Flags |= FlagsToSet;
}
Rewrite NRVO determination. Track NRVO candidates on the parser Scope and apply the NRVO candidate flag to all possible NRVO candidates here, and remove the flags in computeNRVO or upon template instantiation. A variable now has NRVO applied if and only if every return statement in that scope returns that variable. This is nearly optimal. Performs NRVO roughly 7% more often in a bootstrap build of clang. Patch co-authored by Richard Smith. llvm-svn: 207890
2014-05-03 08:41:18 +08:00
void Scope::mergeNRVOIntoParent() {
if (VarDecl *Candidate = NRVO.getPointer()) {
if (isDeclScope(Candidate))
Candidate->setNRVOVariable(true);
}
if (getEntity())
return;
if (NRVO.getInt())
getParent()->setNoNRVO();
else if (NRVO.getPointer())
getParent()->addNRVOCandidate(NRVO.getPointer());
}
[-cxx-abi microsoft] Implement local manglings accurately Summary: The MSVC ABI appears to mangle the lexical scope into the names of statics. Specifically, a counter is incremented whenever a scope is entered where things can be declared in such a way that an ambiguity can arise. For example, a class scope inside of a class scope doesn't do anything interesting because the nested class cannot collide with another nested class. There are problems with this scheme: - It is unreliable. The counter is only incremented when a previously never encountered scope is entered. There are cases where this will cause ambiguity amongst declarations that have the same name where one was introduced in a deep scope while the other was introduced right after in the previous lexical scope. - It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}} will make the mangling of "foo" larger than it need be because the scope counter has been incremented many times. Because of these problems, and practical implementation concerns. We choose not to implement this scheme if the local static or local type isn't visible. The mangling of these declarations will look very similar but the numbering will make far more sense, this scheme is lifted from the Itanium ABI implementation. Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2953 llvm-svn: 202951
2014-03-05 16:57:59 +08:00
void Scope::dump() const { dumpImpl(llvm::errs()); }
void Scope::dumpImpl(raw_ostream &OS) const {
unsigned Flags = getFlags();
bool HasFlags = Flags != 0;
if (HasFlags)
OS << "Flags: ";
while (Flags) {
if (Flags & FnScope) {
OS << "FnScope";
Flags &= ~FnScope;
} else if (Flags & BreakScope) {
OS << "BreakScope";
Flags &= ~BreakScope;
} else if (Flags & ContinueScope) {
OS << "ContinueScope";
Flags &= ~ContinueScope;
} else if (Flags & DeclScope) {
OS << "DeclScope";
Flags &= ~DeclScope;
} else if (Flags & ControlScope) {
OS << "ControlScope";
Flags &= ~ControlScope;
} else if (Flags & ClassScope) {
OS << "ClassScope";
Flags &= ~ClassScope;
} else if (Flags & BlockScope) {
OS << "BlockScope";
Flags &= ~BlockScope;
} else if (Flags & TemplateParamScope) {
OS << "TemplateParamScope";
Flags &= ~TemplateParamScope;
} else if (Flags & FunctionPrototypeScope) {
OS << "FunctionPrototypeScope";
Flags &= ~FunctionPrototypeScope;
} else if (Flags & FunctionDeclarationScope) {
OS << "FunctionDeclarationScope";
Flags &= ~FunctionDeclarationScope;
} else if (Flags & AtCatchScope) {
OS << "AtCatchScope";
Flags &= ~AtCatchScope;
} else if (Flags & ObjCMethodScope) {
OS << "ObjCMethodScope";
Flags &= ~ObjCMethodScope;
} else if (Flags & SwitchScope) {
OS << "SwitchScope";
Flags &= ~SwitchScope;
} else if (Flags & TryScope) {
OS << "TryScope";
Flags &= ~TryScope;
} else if (Flags & FnTryCatchScope) {
OS << "FnTryCatchScope";
Flags &= ~FnTryCatchScope;
Sema: Check that __leave is contained in a __try block. Give scope a SEHTryScope bit, set that in ParseSEHTry(), and let Sema walk the scope chain to find the SEHTry parent on __leave statements. (They are rare enough that it seems better to do the walk instead of giving Scope a SEHTryParent pointer -- this is similar to AtCatchScope.) llvm-svn: 212422
2014-07-07 06:53:19 +08:00
} else if (Flags & SEHTryScope) {
OS << "SEHTryScope";
Flags &= ~SEHTryScope;
Initial support for Win64 SEH IR emission The lowering looks a lot like normal EH lowering, with the exception that the exceptions are caught by executing filter expression code instead of matching typeinfo globals. The filter expressions are outlined into functions which are used in landingpad clauses where typeinfo would normally go. Major aspects that still need work: - Non-call exceptions in __try bodies won't work yet. The plan is to outline the __try block in the frontend to keep things simple. - Filter expressions cannot use local variables until capturing is implemented. - __finally blocks will not run after exceptions. Fixing this requires work in the LLVM SEH preparation pass. The IR lowering looks like this: // C code: bool safe_div(int n, int d, int *r) { __try { *r = normal_div(n, d); } __except(_exception_code() == EXCEPTION_INT_DIVIDE_BY_ZERO) { return false; } return true; } ; LLVM IR: define i32 @filter(i8* %e, i8* %fp) { %ehptrs = bitcast i8* %e to i32** %ehrec = load i32** %ehptrs %code = load i32* %ehrec %matches = icmp eq i32 %code, i32 u0xC0000094 %matches.i32 = zext i1 %matches to i32 ret i32 %matches.i32 } define i1 zeroext @safe_div(i32 %n, i32 %d, i32* %r) { %rr = invoke i32 @normal_div(i32 %n, i32 %d) to label %normal unwind to label %lpad normal: store i32 %rr, i32* %r ret i1 1 lpad: %ehvals = landingpad {i8*, i32} personality i32 (...)* @__C_specific_handler catch i8* bitcast (i32 (i8*, i8*)* @filter to i8*) %ehptr = extractvalue {i8*, i32} %ehvals, i32 0 %sel = extractvalue {i8*, i32} %ehvals, i32 1 %filter_sel = call i32 @llvm.eh.seh.typeid.for(i8* bitcast (i32 (i8*, i8*)* @filter to i8*)) %matches = icmp eq i32 %sel, %filter_sel br i1 %matches, label %eh.except, label %eh.resume eh.except: ret i1 false eh.resume: resume } Reviewers: rjmccall, rsmith, majnemer Differential Revision: http://reviews.llvm.org/D5607 llvm-svn: 226760
2015-01-22 09:36:17 +08:00
} else if (Flags & SEHExceptScope) {
OS << "SEHExceptScope";
Flags &= ~SEHExceptScope;
[-cxx-abi microsoft] Implement local manglings accurately Summary: The MSVC ABI appears to mangle the lexical scope into the names of statics. Specifically, a counter is incremented whenever a scope is entered where things can be declared in such a way that an ambiguity can arise. For example, a class scope inside of a class scope doesn't do anything interesting because the nested class cannot collide with another nested class. There are problems with this scheme: - It is unreliable. The counter is only incremented when a previously never encountered scope is entered. There are cases where this will cause ambiguity amongst declarations that have the same name where one was introduced in a deep scope while the other was introduced right after in the previous lexical scope. - It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}} will make the mangling of "foo" larger than it need be because the scope counter has been incremented many times. Because of these problems, and practical implementation concerns. We choose not to implement this scheme if the local static or local type isn't visible. The mangling of these declarations will look very similar but the numbering will make far more sense, this scheme is lifted from the Itanium ABI implementation. Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2953 llvm-svn: 202951
2014-03-05 16:57:59 +08:00
} else if (Flags & OpenMPDirectiveScope) {
OS << "OpenMPDirectiveScope";
Flags &= ~OpenMPDirectiveScope;
[OPENMP] Loop canonical form analysis (Sema) This patch implements semantic analysis to make sure that the loop is in OpenMP canonical form. This is the form required for 'omp simd', 'omp for' and other loop pragmas. Differential revision: http://reviews.llvm.org/D3778 llvm-svn: 210095
2014-06-03 18:16:47 +08:00
} else if (Flags & OpenMPLoopDirectiveScope) {
OS << "OpenMPLoopDirectiveScope";
Flags &= ~OpenMPLoopDirectiveScope;
} else if (Flags & OpenMPSimdDirectiveScope) {
OS << "OpenMPSimdDirectiveScope";
Flags &= ~OpenMPSimdDirectiveScope;
[-cxx-abi microsoft] Implement local manglings accurately Summary: The MSVC ABI appears to mangle the lexical scope into the names of statics. Specifically, a counter is incremented whenever a scope is entered where things can be declared in such a way that an ambiguity can arise. For example, a class scope inside of a class scope doesn't do anything interesting because the nested class cannot collide with another nested class. There are problems with this scheme: - It is unreliable. The counter is only incremented when a previously never encountered scope is entered. There are cases where this will cause ambiguity amongst declarations that have the same name where one was introduced in a deep scope while the other was introduced right after in the previous lexical scope. - It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}} will make the mangling of "foo" larger than it need be because the scope counter has been incremented many times. Because of these problems, and practical implementation concerns. We choose not to implement this scheme if the local static or local type isn't visible. The mangling of these declarations will look very similar but the numbering will make far more sense, this scheme is lifted from the Itanium ABI implementation. Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2953 llvm-svn: 202951
2014-03-05 16:57:59 +08:00
}
if (Flags)
OS << " | ";
}
if (HasFlags)
OS << '\n';
if (const Scope *Parent = getParent())
OS << "Parent: (clang::Scope*)" << Parent << '\n';
OS << "Depth: " << Depth << '\n';
MS ABI: Implement the MSVC 2015 scheme for scope disambiguation consider C++ that looks like: inline int &f(bool b) { if (b) { static int i; return i; } static int i; return i; } Both 'i' variables must have distinct (and stable) names for linkage purposes. The MSVC 2013 ABI would number the variables using a count of the number of scopes that have been created. However, the final 'i' returns to a scope that has already been created leading to a mangling collision. MSVC 2015 fixes this by giving the second 'i' the name it would have if it were declared before the 'if'. However, this results in ABI breakage because the mangled name, in cases where there was no ambiguity, would now be different. We implement the new behavior and only enable it if we are targeting the MSVC 2015 ABI, otherwise the old behavior will be used. This fixes PR18131. llvm-svn: 232766
2015-03-20 05:54:30 +08:00
OS << "MSLastManglingNumber: " << getMSLastManglingNumber() << '\n';
OS << "MSCurManglingNumber: " << getMSCurManglingNumber() << '\n';
[-cxx-abi microsoft] Implement local manglings accurately Summary: The MSVC ABI appears to mangle the lexical scope into the names of statics. Specifically, a counter is incremented whenever a scope is entered where things can be declared in such a way that an ambiguity can arise. For example, a class scope inside of a class scope doesn't do anything interesting because the nested class cannot collide with another nested class. There are problems with this scheme: - It is unreliable. The counter is only incremented when a previously never encountered scope is entered. There are cases where this will cause ambiguity amongst declarations that have the same name where one was introduced in a deep scope while the other was introduced right after in the previous lexical scope. - It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}} will make the mangling of "foo" larger than it need be because the scope counter has been incremented many times. Because of these problems, and practical implementation concerns. We choose not to implement this scheme if the local static or local type isn't visible. The mangling of these declarations will look very similar but the numbering will make far more sense, this scheme is lifted from the Itanium ABI implementation. Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2953 llvm-svn: 202951
2014-03-05 16:57:59 +08:00
if (const DeclContext *DC = getEntity())
OS << "Entity : (clang::DeclContext*)" << DC << '\n';
Rewrite NRVO determination. Track NRVO candidates on the parser Scope and apply the NRVO candidate flag to all possible NRVO candidates here, and remove the flags in computeNRVO or upon template instantiation. A variable now has NRVO applied if and only if every return statement in that scope returns that variable. This is nearly optimal. Performs NRVO roughly 7% more often in a bootstrap build of clang. Patch co-authored by Richard Smith. llvm-svn: 207890
2014-05-03 08:41:18 +08:00
if (NRVO.getInt())
MS ABI: Implement the MSVC 2015 scheme for scope disambiguation consider C++ that looks like: inline int &f(bool b) { if (b) { static int i; return i; } static int i; return i; } Both 'i' variables must have distinct (and stable) names for linkage purposes. The MSVC 2013 ABI would number the variables using a count of the number of scopes that have been created. However, the final 'i' returns to a scope that has already been created leading to a mangling collision. MSVC 2015 fixes this by giving the second 'i' the name it would have if it were declared before the 'if'. However, this results in ABI breakage because the mangled name, in cases where there was no ambiguity, would now be different. We implement the new behavior and only enable it if we are targeting the MSVC 2015 ABI, otherwise the old behavior will be used. This fixes PR18131. llvm-svn: 232766
2015-03-20 05:54:30 +08:00
OS << "NRVO not allowed\n";
Rewrite NRVO determination. Track NRVO candidates on the parser Scope and apply the NRVO candidate flag to all possible NRVO candidates here, and remove the flags in computeNRVO or upon template instantiation. A variable now has NRVO applied if and only if every return statement in that scope returns that variable. This is nearly optimal. Performs NRVO roughly 7% more often in a bootstrap build of clang. Patch co-authored by Richard Smith. llvm-svn: 207890
2014-05-03 08:41:18 +08:00
else if (NRVO.getPointer())
OS << "NRVO candidate : (clang::VarDecl*)" << NRVO.getPointer() << '\n';
[-cxx-abi microsoft] Implement local manglings accurately Summary: The MSVC ABI appears to mangle the lexical scope into the names of statics. Specifically, a counter is incremented whenever a scope is entered where things can be declared in such a way that an ambiguity can arise. For example, a class scope inside of a class scope doesn't do anything interesting because the nested class cannot collide with another nested class. There are problems with this scheme: - It is unreliable. The counter is only incremented when a previously never encountered scope is entered. There are cases where this will cause ambiguity amongst declarations that have the same name where one was introduced in a deep scope while the other was introduced right after in the previous lexical scope. - It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}} will make the mangling of "foo" larger than it need be because the scope counter has been incremented many times. Because of these problems, and practical implementation concerns. We choose not to implement this scheme if the local static or local type isn't visible. The mangling of these declarations will look very similar but the numbering will make far more sense, this scheme is lifted from the Itanium ABI implementation. Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2953 llvm-svn: 202951
2014-03-05 16:57:59 +08:00
}