Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 343710

Summary:	[Xbase] Visibility computation of feature calls incomplete
Product:	[Modeling] TMF	Reporter:	Krzysztof Kowalczyk <kowalczyk.krzysztof>
Component:	Xtext	Assignee:	Project Inbox <tmf.xtext-inbox>
Status:	NEW ---	QA Contact:
Severity:	normal
Priority:	P3	CC:	sebastian.zarnekow, sven.efftinge
Version:	2.0.0
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Krzysztof Kowalczyk

2011-04-24 15:16:56 EDT

Xtend compiler does not check if given type is visible in given context e.g. if one references package-visible class from different package it leads to Java error but Xtend compiler does not complain.

Example is available on:
https://github.com/KrzysztofKowalczyk/Tests/blob/master/src/Visibility.xtend

Comment 1 Sebastian Zarnekow

2011-05-04 06:11:45 EDT

Preliminary scheduled for 2.0RC1

Comment 2 Sven Efftinge

2011-05-04 09:59:10 EDT

postponed to SR1

Comment 3 Sven Efftinge

2011-09-19 07:53:23 EDT

The VisisbilityService and DefaultJvmFeatureDescriptionProvider doesn't take the actual receiver into account when detecting whether a certain feature is visible or not.

Consider the following case:

class MyXtendClass {
  def foo() {
    new Object().clone // clone should be marked with an error
    this.clone // this is ok
  }
}

Comment 4 Sven Efftinge

2011-09-26 05:33:54 EDT

I don't think we'll be able to fix this completely for SR2, so we should at least have a small 'hack' which is to remove 'clone' and 'finalize' from the scope (or maybe just from the list of proposals). 
Since currently those methods are always proposed as valid.

Comment 5 Sven Efftinge

2011-10-13 10:57:08 EDT

I have removed Object.finalize() and Object.clone() from the list of proposals.

Comment 6 Sven Efftinge

2012-11-21 04:07:01 EST

*** Bug 342035 has been marked as a duplicate of this bug. ***

Comment 7 Sebastian Zarnekow

2013-01-23 14:59:38 EST

Fixed validation for member access was pushed and will be available with the type system.

We still need to validate type references themselves. Furthermore, super type computation has to take the current context into account:

The super type of StringBuilder in StringBuffer is AbstractStringBuilder (+ some interfaces) as long as the context is the package java.lang, other contexts have to yield Object + some interfaces.

Comment 8 Sebastian Zarnekow

2014-02-04 05:49:39 EST

Other pending issues with default visibility:

package a;

class A {
  void m()
}

package b;

class B extends A {}

package a;

class C extends B {
  // m() is not visible
}

There may be issues with members of nested types, too.