Where from "has private access in " is logged? I'd like to suppress it

[Gabriele Kahlout]

> I always get the scope for the statement before the faulty one (which will
> be replaced). By then the scope is correct. This worked except with the case
> where the faulty stmt is the first in the enclosing block.
> What I tried there is getting the scope for the treepath up to the
> enclosing block but that gives the same result as getting it for the first
> statement in that block (it seems). I wasn't expecting this, is this a bug
> or a feature?
>

I'd worked around this as follows by changing the tree and splitting a
variable declaration.

if (stmt instanceof JCVariableDecl) {
            JCExpression exp = ((JCVariableDecl) stmt).init;
            ((JCVariableDecl) stmt).init = null;
            TreePath path = TreePath.getPath(cut, stmt);
            validScope = trees.getScope(path);
            ((JCVariableDecl) stmt).init = exp;
        }

But this doesn't work if the first statement is an assignment to a private
variable (eg. pc.i  = 5).

And this other bug/feature:
If I get the scope of the TreePath of a parameter it doesn't include the
parameters before it (it included).
So for a method:
void m(int a, int b){

}
The scope at "int b" doesn't include either "a" nor "b".

I can see a work-around of injecting a dummy stmt and use that path, and
then remove the dummy.



>
>
>
>
> On Fri, Feb 25, 2011 at 9:02 PM, Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>> On 02/24/2011 10:10 PM, Gabriele Kahlout wrote:
>>
>>> Awesome! Any reference to the bug and to the (first) version of the jdk
>>> where this is fixed? Why wasn't this fixed against jdk6 versions too?
>>>
>>
>> There is no specific bug relating to your issue, meaning that the issue
>> has been fixed as part of some other work.  There are over 30 changesets for
>> the file in question and I would estimate that about 50% of the lines of
>> code have been changed (in Resolve.java.)   Regrettably, it is not always
>> practical or desirable to back port all work into earlier releases.
>>
>> -- Jon
>>
>>
>>
>
>
> --
> Regards,
> K. Gabriele
>
> --- unchanged since 20/9/10 ---
> P.S. If the subject contains "[LON]" or the addressee acknowledges the
> receipt within 48 hours then I don't resend the email.
> subject(this) ∈ L(LON*) ∨ ∃x. (x ∈ MyInbox ∧ Acknowledges(x, this) ∧
> time(x) < Now + 48h) ⇒ ¬resend(I, this).
>
> If an email is sent by a sender that is not a trusted contact or the email
> does not contain a valid code then the email is not received. A valid code
> starts with a hyphen and ends with "X".
> ∀x. x ∈ MyInbox ⇒ from(x) ∈ MySafeSenderList ∨ (∃y. y ∈ subject(x) ∧ y ∈
> L(-[a-z]+[0-9]X)).
>
>


-- 
Regards,
K. Gabriele

--- unchanged since 20/9/10 ---
P.S. If the subject contains "[LON]" or the addressee acknowledges the
receipt within 48 hours then I don't resend the email.
subject(this) ∈ L(LON*) ∨ ∃x. (x ∈ MyInbox ∧ Acknowledges(x, this) ∧ time(x)
< Now + 48h) ⇒ ¬resend(I, this).

If an email is sent by a sender that is not a trusted contact or the email
does not contain a valid code then the email is not received. A valid code
starts with a hyphen and ends with "X".
∀x. x ∈ MyInbox ⇒ from(x) ∈ MySafeSenderList ∨ (∃y. y ∈ subject(x) ∧ y ∈
L(-[a-z]+[0-9]X)).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20110330/feb61546/attachment.html