[cfe-dev] Bug 18275 - Incorrect const qualifier behavior in definition.

[suyog sarda]

Gentle Ping !!


On Mon, Feb 3, 2014 at 10:25 PM, suyog sarda <sardask01 at gmail.com> wrote:

> Gentle Ping ! Please help in reviewing this.
>
>
> On Sun, Feb 2, 2014 at 9:52 PM, suyog sarda <sardask01 at gmail.com> wrote:
>
>> Hi all,
>>
>> Thanks to Richard for pointing out the specifics.
>>
>> Attaching patch for PR18275. Please review and also suggest where to add
>> the test case.
>>
>>
>> --
>> With regards,
>> Suyog Sarda
>>
>>
>> On Fri, Jan 31, 2014 at 12:43 AM, Richard Smith <metafoo at gmail.com>wrote:
>>
>>> On Thu Jan 30 2014 at 6:21:34 AM, suyog sarda <sardask01 at gmail.com>
>>> wrote:
>>>
>>>> Ping !! Any help would be appreciated on this.
>>>>
>>>> On Thu, Jan 30, 2014 at 1:04 AM, suyog sarda <sardask01 at gmail.com>wrote:
>>>>
>>>> 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?
>>>>
>>>>
>>> The above is what happens when we parse a function declaration /
>>> definition, but it's not the code path taken during template instantiation.
>>>
>>>  When we instantiate a class template, we instantiate declarations of
>>> all the member functions of that class template. When we later instantiate
>>> the definition of one of those functions, we do not instantiate another
>>> declaration (potentially with slightly different actual parameter types);
>>> instead, we reuse the prior declaration.
>>>
>>> Look into Sema::InstantiateFunctionDefinition, and in particular its
>>> call to addInstantiatedParametersToScope, to see where we reuse the prior
>>> parameters.
>>>
>>
>>
>>
>> --
>> With regards,
>> Suyog Sarda
>>
>
>
>
> --
> With regards,
> Suyog Sarda
>



-- 
With regards,
Suyog Sarda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140207/30b171c0/attachment.html>