Auto-Complete doesn't find D modules in symlink source folders
ahmetsait opened this issue · comments
I have installed DDT in fresh Eclipse 64bit platform binary on Ubuntu 14.04.
Everything went well and I believe dub installation is correct -> copied "dub" executable into "/bin" directory...
I create a simple hello world project and it compiles succesfully via GDC. [Ctrl + Space] triggers auto-completion as expected, none of the imported module functions appear inside it, ie: I can't find 'writeln' function in auto-complete list. Only the language specific keywords and main function (as DDT parses the project source) displayed in the list. Mouse-hover on 'std.stdio' show up "Could not resolve reference: std.stdio" message.
I'm not sure if it's an issue about the plugin itself, it may be my misusage...
Thanks for your efforts in advance.
*EDIT: The bug is cause because /usr/include/d/4.8.2 - the standard library folder - is a symlink ... *
It seems like DDT is not finding the location of the standard library source folders. If you open a D project in the Project Explorer, and then click the "D Standard Library" entry, what entries appear under it? There should be two folders there.
There is one included directory under 'D Standart Library' entry which is "/usr/include/d/4.8.2". This is a link-dir pointing to "/usr/include/d/4.8". Here it is:
$ ls -la /usr/include/d/*
lrwxrwxrwx 1 root root 3 Nis 5 2014 /usr/include/d/4.8.2 -> 4.8
/usr/include/d/4.8:
toplam 60
drwxr-xr-x 8 root root 4096 Nis 6 17:13 .
drwxr-xr-x 3 root root 4096 Nis 6 17:13 ..
drwxr-xr-x 5 root root 4096 Nis 6 17:13 core
-rw-r--r-- 1 root root 3948 Nis 5 2014 crc32.d
-rw-r--r-- 1 root root 2297 Nis 5 2014 __entrypoint.di
drwxr-xr-x 3 root root 4096 Nis 6 17:13 etc
drwxr-xr-x 2 root root 4096 Nis 6 17:13 gcc
-rw-r--r-- 1 root root 16476 Nis 5 2014 object.di
drwxr-xr-x 7 root root 4096 Nis 6 17:13 std
drwxr-xr-x 3 root root 4096 Nis 6 17:13 x86_64-linux-gnu
drwxr-xr-x 3 root root 4096 Nis 6 17:13 x86_64-linux-gnux32
That's the console output after opening project:
************ Resolving DUB project: DubStep ************
> dub describe
{
"rootPackage": "dubstep",
"mainPackage": "dubstep",
"packages": [
{
"workingDirectory": "",
"copyright": "",
"versions": [],
"targetFileName": "dubstep",
"dependencies": [],
"version": "~master",
"debugVersions": [],
"postGenerateCommands": [],
"libs": [],
"targetName": "dubstep",
"lflags": [],
"name": "dubstep",
"importPaths": [
"source/"
],
"homepage": "",
"authors": [],
"preGenerateCommands": [],
"buildRequirements": [],
"postBuildCommands": [],
"targetType": "executable",
"mainSourceFile": "source/app.d",
"copyFiles": [],
"preBuildCommands": [],
"targetPath": "",
"dflags": [],
"license": "",
"path": "/home/user/workspace/DubStep/",
"description": "Hello World - A minimal DUB bundle.",
"options": [],
"stringImportPaths": [],
"files": [
{
"path": "source/app.d",
"type": "source"
}
]
}
],
"configuration": "application",
"compiler": "gdc",
"architecture": [
"x86_64"
],
"platform": [
"linux",
"posix"
]
} ^^^ Terminated, exit code: 0 ^^^
That's really odd. "/usr/include/d/4.8.2" appears to have the correct standard library source structure, so if that dir is found by DDT and appears in the "D Standard Library" entry, is should find the std-lib modules. When you attempt completion, is there anything out of the ordinary in the Eclipse error log (see "Help/About/Installation Details/Configuration/Error Log"), any exceptions or other strange messages ?
I couldn't find anything strange, no error about ddt itself. That's even more strange...
If you invoke Content Assist after import, does any module show up at all? (note that you need a space after "import" , like this: import 【invoke CA here】 )
Sorry for the late response;
The only module appears in Content Assist after import is the "DubStep" module which is my program's main module. DDT clearly shows that it's able to parse my project but not standart library.
I wonder if it's ever going to be verified...
@NightmareX1337 Could you perhaps give a hand here, and try to run DDT under a debugger, to help find this? Otherwise we seem to be stuck. I've added more info to the Developers guide: https://github.com/bruno-medeiros/DDT/#developers-guide so that it should be easy for someone to start DDT under a debugger, even if you don't have knowledge about Eclipse plug-in development.
One good place to start is to but a breakpoint in:
dtool.ast.references.RefModule.doPerformNameLookup(CommonScopeLookup)
and then try the import 【invoke CA here】 case I mentioned above, then take it from there.
Another interesting breakpoint is in the constructor: dtool.engine.DubBundleResolution.DubBundleResolution(SemanticManager, ResolvedManifest, StandardLibraryResolution)
And the check the contents of stdLibResolution when the breakpoint triggers. (stdLibResolution should list the modules found in the standard library dependency)
@bruno-medeiros
I can verify that I have this exact same problem, with GDC.
I have my D Standard Lib here: /usr/include/d/4.9.2
The project is working fine, and can parse my own libraries and projects in the source directory tree. It compiles fine, and runs fine, as normal. However code completion, assist, shows nothing.
Same setup as @NightmareX1337 with the same issue.
Good news, I seem to have been able to replicate this on my Linux box.
The bug is cause because /usr/include/d/4.8.2 is a symlink ...
Awesome! Thanks!
Huge thanks really!