[cfe-dev] Bug 18275 - Incorrect const qualifier behavior in definition.
suyog sarda
sardask01 at gmail.com
Wed Jan 29 11:34:38 PST 2014
Hi,
I was looking at bug 18275 - Incorrect const qualifier behavior in
definition.
The declaration of A::f has a const. The definition doesn't.
*template <typename T>struct A{ void f(const int);};template <typename
T>void A<T>::f(int x){ x = 0;}void f(){ A<float> a; a.f(0);}*
Clang produces an error:
test.cpp:10:7: error: read-only variable is not assignable
x = 0;
~ ^
test.cpp:26:7: note: in instantiation of member function 'A<float>::f'
requested here
a.f(0);
^
It only happens for templateclasses. In exact the same situation with a
regular class everything compiles well.
*struct B{ void f(const int);};void B::f(int x){ x = 0;}void f(){
B b; b.f(0);}*GCC compiles both examples without an error.
According to my understanding, the standard 13.1/3 states that Parameter
declarations that differ only in the presence or absence of const and/or
volatile are equivalent. That is, the const and volatile type-specifiers
for each parameter type are ignored when determining which function
is being declared, defined, or called. So clang is wrong to throw error in
template case.
After following the code path for above examples, i came across function
name "*Sema::ActOnFunctionDeclarator*" in SemaDecl.cpp file, where
everytime a function is redeclared/defined, its new declaration is created '
*CreateNewFunctionDecl*', and its parameters are copied in following lines
of code (l*ine number 6890 in SemaDecl.cpp in latest trunk version*)
*for (unsigned i = 0, e = FTI.NumArgs; i != e; ++i) { ParmVarDecl
*Param = cast<ParmVarDecl>(FTI.ArgInfo[i].Param);
assert(Param->getDeclContext() != NewFD && "Was set before ?");
Param->setDeclContext(NewFD); Params.push_back(Param);*
I couldn't find exactly where the codepath gets different for above two
cases. For both TC above, parameters get copied in above lines of code. Can
someone help in pointing out, where does the properties of function
parameters/variables are set and where does those properties get reset on
redeclaration/definition? Am i going wrong somewhere in above code analysis?
--
With regards,
Suyog Sarda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140130/957d199f/attachment.html>
More information about the cfe-dev
mailing list