| Summary: | links to type local methods not resolved in PHPDoc tooltip | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Jacek Pospychala <jacek.pospychala> |
| Component: | PDT | Assignee: | PHP UI <php.ui-inbox> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | P2 | CC: | mauromol, silviya |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
|
Description
Jacek Pospychala
QA note:
This is the whole sample code used for testing/verification:
class Test
{
/**
* @see ab()
*/
public function aa()
{
}
/**
* @see Test::aa()
*/
public function ab()
{
}
}
If I hit F2 on aa I see the link to ab, but if I click it does not change the
contents of the phpDoc window.
So, if we click the link to ab(), what phpdoc should we display? The global function ab() or the method ab() in class Test? According to http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_tags.see.pkg.html If we type @see ab(), I think we should display the PHPDoc of global function ab(), right? I'd search for method in following order: in current class, then in parent class(es) and then in global scope. (In reply to comment #0) > from bug 324656 > > 1. If you have @see <class_name>::<method_name> it works. Unfortunately, in my environment this case doesn't work either :-( (In reply to comment #3) > If we type @see ab(), I think we should display the PHPDoc of global function > ab(), right? I would interpret it in another way. First of all, if you don't have punctuation (i.e. ab without "()") the phpDoc documentation says it does the following: 1. is elementname the name of a class? 2. is elementname the name of a procedural page? (file.ext) 3. is elementname the name of a define? 4. if the DocBlock containing the @see is in a class: 1. is elementname a method? 2. is elementname a variable? 5. is elementname a function? In this case, a method within the class is searched before a function. I would expect something alike when I specify the "()", otherwise the two cases would be inconsistent. Secondly, if you look at the example you'll see that "@see parent_method()" is meant to search for the method named "parent_method" within the class (and through its hierarchy). (In reply to comment #5) > Unfortunately, in my environment this case doesn't work either :-( I just tried in another environment (but with the same versions of Eclipse and PDT, now on Windows 7 64-bit) and still I can't see this working even with the syntax <class name>::<method name>. In the provided example (for which in the other report I forgot to say that the file is named test.php) if I hit F2 on ab and then click on the link to Test::aa() in the phpDoc window, nothing happens! Sylvie, do you remember on which version did you verified bug 324656? Mauro is using PHP Development Tools (PDT) SDK Feature 2.2.1.v20101001-2300-53184QAN4JBQgLYPWMLcXn6Na9Od org.eclipse.php.sdk.feature.group this imho should contain the fix, but I've not been verifying that. As I wrote in comment #9 in bug #324656: "I also have the 2.2.1.v20101001 and this works OK there." That was about the initial example from description of bug #324656. Your first example works there. That is why the bug was closed. As for the new one: I just double check the new example provided by Mauro on the same PDT build and I can confirm that none of the 2 cases work. The @see <class_name>::<method_name> case works on my testing environment, but it seems that my PDT is a bit more updated (17.10.2010) OK ... I think I see something related to using F2.
Consider case 1:
/**
* @see Test::aa()
*/
public function ab()
{
}
1. If you point aa() with the mouse, the tip auto-opens and if you click on the link it works (also in 2.2.1.v20101001)
2. If you stand on aa() and use F2 to open the tip, the link does not work (also I see exception thrown - see below)
3. This is valid for 2.2.1.v20101001 and for more recent as well. OS does not matter.
4. The other case @see <method_name> (without <class_name>) does not work in both ways and produces nothing (not even exception)
null
Error
Fri Oct 22 13:55:53 EEST 2010
Unhandled event loop exception
java.lang.ClassCastException: org.eclipse.jface.internal.text.html.BrowserInformationControl$3 cannot be cast to org.eclipse.php.internal.ui.editor.hover.PHPDocumentationBrowserInformationControlInput
at org.eclipse.php.internal.ui.editor.hover.PHPDocumentationHover$1.handleInlineLink(PHPDocumentationHover.java:407)
at org.eclipse.php.internal.ui.documentation.PHPElementLinks$1.changing(PHPElementLinks.java:154)
at org.eclipse.swt.browser.IE$6.handleEvent(IE.java:440)
at org.eclipse.swt.ole.win32.OleEventTable.sendEvent(OleEventTable.java:55)
at org.eclipse.swt.ole.win32.OleEventSink.notifyListener(OleEventSink.java:145)
at org.eclipse.swt.ole.win32.OleEventSink.Invoke(OleEventSink.java:120)
at org.eclipse.swt.ole.win32.OleEventSink.access$1(OleEventSink.java:97)
at org.eclipse.swt.ole.win32.OleEventSink$1.method6(OleEventSink.java:71)
at org.eclipse.swt.internal.ole.win32.COMObject.callback6(COMObject.java:119)
at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2459)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3655)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574)
at org.eclipse.equinox.launcher.Main.run(Main.java:1407)
(In reply to comment #10) > OK ... I think I see something related to using F2. I confirm all the results of Silviya's investigation. Sorry, I had not seen the exception in the error log before. (In reply to comment #10) > OK ... I think I see something related to using F2. > Consider case 1: > /** > * @see Test::aa() > */ > public function ab() > { > > } > > 1. If you point aa() with the mouse, the tip auto-opens and if you click on the > link it works (also in 2.2.1.v20101001) > 2. If you stand on aa() and use F2 to open the tip, the link does not work > (also I see exception thrown - see below) Saw my mistake now ... I meant ab() of course and not aa() in point 1 and 2 ... :) Ok, so there's two bugs here: 1. ClassCastException, when pressing F2 2. PHPdoc link doesn't work for methods, if they're not prefixed with "<Class>::" I'll leave them in this single bug, because ClassCastException seems to be easy to fix. If not, eventual resolver may split into two bugs... Thank you to all of you for helping to narrow down this bug! Other cases that do not work:
class Test
{
/**
* My var description
* @var int
*/
private $myVar = 1;
/**
* @see $myVar
* @see Test::$myVar
*/
public function ac()
{
}
}
In the first case (@see $myVar) the content doesn't change, while according to:
http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_tags.see.pkg.html
it should search for a variable in the current class.
In the second case (@see Test::$myVar) the content switches to an undefined method Test::myVar(), which is of course wrong (the "$" clearly says that you want to reference a variable, not a function).
|