Commit Graph

9 Commits

Author SHA1 Message Date
David Majnemer 2206bf5d5b [-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 08:57:59 +00:00
Serge Pavlov 09f9924acf 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 15:05:00 +00:00
Chandler Carruth b3b8ea8007 Revert r193073 and the attempt to fix it in r193170.
This patch wasn't reviewed, and isn't correctly preserving the behaviors
relied upon by QT. I don't have a direct example of fallout, but it
should go through the standard code review process. For example, it
should never have removed the QT test case that was added when fixing
those users.

llvm-svn: 193174
2013-10-22 18:07:04 +00:00
Serge Pavlov 6652921d5a 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; }); )

Such usage must be diagnosed as an error, GCC rejects it. To recognize
this and similar patterns the flags BreakScope and ContinueScope are
temporarily turned off while parsing condition expression.

Differential Revision: http://llvm-reviews.chandlerc.com/D1762

llvm-svn: 193073
2013-10-21 09:34:44 +00:00
James Molloy 6f8780bed1 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 10:24:19 +00:00
Argyrios Kyrtzidis 5929ef2ee7 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: 151667
2012-02-28 23:39:14 +00:00
James Molloy 051390fffa 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.

llvm-svn: 151638
2012-02-28 18:12:11 +00:00
Richard Smith 1002d10aaa 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 01:35:32 +00:00
John McCall 8fb0d9d24a 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-01 22:35:37 +00:00