bcm5719-llvm - Project Ortega BCM5719 LLVM

	Commit message (Collapse)	Author	Age	Files	Lines
*	Add a test for r174980, that we used to accept	Dmitri Gribenko	2013-02-12	1	-2/+10
\| \| \| \|	llvm-svn: 175005
*	Accept over-qualified constructor in MSVC emulation mode	Dmitri Gribenko	2013-02-12	1	-1/+5
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	MSVC accepts this: class A { A::A(); }; Clang accepts regular member functions with extra qualification as an MS extension, but not constructors. This changes the parser to defer rejecting qualified constructors so that the same Sema logic can apply to constructors as regular member functions. This also improves the error message when MS extensions are disabled (in my opinion). Before it was: /Users/jason/Desktop/test.cpp:2:8: error: expected member name or ';' after declaration specifiers A::A(); ~~~~ ^ 1 error generated. After: /Users/jason/Desktop/test.cpp:2:6: error: extra qualification on member 'A' A::A(); ~~~^ 1 error generated. Patch by Jason Haslam. llvm-svn: 174980
*	Prior to adding the new "expected-no-diagnostics" directive to ↵	Andy Gibbs	2012-10-19	1	-0/+1
\| \| \| \| \| \|	VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive. llvm-svn: 166280
*	Reimplement constructor declarator parsing to cope with template-ids	Douglas Gregor	2010-01-13	1	-0/+42
	that name constructors, the endless joys of out-of-line constructor definitions, and various other corner cases that the previous hack never imagined. Fixes PR5688 and tightens up semantic analysis for constructor names. Additionally, fixed a problem where we wouldn't properly enter the declarator scope of a parenthesized declarator. We were entering the scope, then leaving it when we saw the ")"; now, we re-enter the declarator scope before parsing the parameter list. Note that we are forced to perform some tentative parsing within a class (call it C) to tell the difference between C(int); // constructor and C (f)(int); // member function which is rather unfortunate. And, although it isn't necessary for correctness, we use the same tentative-parsing mechanism for out-of-line constructors to improve diagnostics in icky cases like: C::C C::f(int); // error: C::C refers to the constructor name, but // we complain nicely and recover by treating it as // a type. llvm-svn: 93322