Community
Participate
Working Groups
The code snippet below illustrates a deficiency in the parser's 'auto' type deduction. The lines marked [1] and the lines marked [2] differ only by the use of "auto" to deduce the type of a variable returned from a function. In [1], which doesn't use 'auto', everything is fine. In [2], however, which does use 'auto', something goes wrong in the parser/indexer. There are no errors, but there are the following problems: A) When you type "r2.", auto-completion only offers meow() as a choice, not woof(). In [1], auto-completion offers both meow() and woof() as choices. B) "Open Declaration" on the "meow" in "r2.meow()" works fine. But on the "woof" in "r2.woof()", it gives the error "Could not find symbol 'woof' in index". In [1], "Open Declaration" works for both functions. C) The "meow" and "woof" in "r2.meow()" and "r2.woof()" are syntax-colored differently from the "meow" and "woof" in "r1.meow()" and "r1.woof()" (the r1 calls have the color specified for "Method" in the Syntax Coloring Preferences, while the r2 calls have the color specified for "Function"). This is interesting because both "meow" and "woof" are affected, whereas in (A) and (B) only "woof" was affected. Any of the following causes the problems to go away: - removing the rvalue reference in the argument type of fubar() - removing the use of "remove_reference" - passing the literal "0" instead of the variable "z" as argument to fubar() [ASIDE: By the way, it would be *super cool* to have a feature where you select a variable or expression, and CDT tells you what it thinks the type of that variable or expression is.] Here is the code: template<typename T> struct remove_reference { typedef T type; }; template<typename T> struct remove_reference<T&> { typedef T type; }; template<typename T> struct remove_reference<T&&> { typedef T type; }; template<class T> struct base { void woof(); }; template <typename T> struct derived : public base<T> { void meow(); }; template <class T> derived<typename remove_reference<T>::type> fubar(T&&); int main() { int z; // works fine derived<int> r1 = fubar(z); // [1] r1.meow(); // [1] r1.woof(); // [1] // something wrong here auto r2 = fubar(z); // [2] r2.meow(); // [2] r2.woof(); // [2] return 0; }
Root cause is a bogus type deductions that allowed for substituting rvalue references for references and vice versa. Added testcase, fixed in 8.0.1 > 20110720.
*** cdt git genie on behalf of 351927 *** Bug 351927: Argument deduction with reference types [*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=5c46a13bd31fe7a9f5e19a629b965cb1ca66ea47
*** cdt git genie on behalf of 351927 *** Bug 351927: Argument deduction with reference types [*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=0613de1b428e831220ab958b69752ed2eb503505