VisualD's Intellisense not workign with gtk

[Rainer Schuetze via Digitalmars-d-ide]

On 07.08.2017 21:56, Johnson wrote:
>> So, if you can provide full source files instead of single line 
>> snippets of things that don't work, it will likely be a lot easier to 
>> reproduce and fix the semantic engine. Also, you might want to add 
>> them as reports to https://issues.dlang.org/ for component visuald so 
>> they don't get lost.
> 
> Could Dscanner not be used?
> 
> https://github.com/dlang-community/D-Scanner
> 
> The "--ast" or "--xml" options will dump the complete abstract syntax 
> tree of the given source file to standard output in XML format.

Dscanner is more a lint-like tool, not usually used for Intellisense. 
That's rather done by DCD (https://github.com/dlang-community/DCD).

Last time I checked, DCD was well behind D_Parser (a fork of 
https://github.com/aBothe/D_Parser) used by Visual D: no mixins, CTFE, 
UFCS, limited template support.


> 
> Simply match the source line number up with the ast, extract the type. 
> This type then is used as a look up in the JSON(it should be there 
> somewhere, if not, update dmd to add type information so cross 
> referencing can be used).
> 
> IMO, DMD should be able to generate basically every cross-relation that 
> one needs to do proper debugging. When it evaluates a mixin it can 
> generate whatever info is required and even allow debugging mixins since 
> dmd invokes dmd again to generate the mixin output, insert a debugger in 
> between.
> 
> It seems that the main problem is that dmd itself is not very well 
> designed to support these types of features. Maybe that is the place to 
> start?
> 
> Basically every line in the source code to correspond to a line in the 
> binary(although, not a one to one function and not even a function at 
> all, one can still encode such a mapping to find out what is where) and 
> vice versa. All type info, mixin expansions, etc should be easily 
> understood. All this has to work else dmd couldn't compile them.
> 
> The only problem seems to be dmd extracting and presenting the 
> information in such a way that Visual D can understand it?
> 
> 
> In a sense, I don't see why any semantic analysis has to be done. 
> Everything is already done by DMD and it will do it perfectly(because it 
> has to).
> 
> It would probably be better to add the proper modifications to DMD so 
> that it can self-regulate with changes in DMD or the grammar.  This 
> prevents having to update any separate utility every time dmd changes 
> something.
> 
> I don't know if dmd as a library will really add any thing new unless it 
> already has the functionality to do what is required... but if that's 
> the case it should also be able, then to output all the required info to 
> a file that Visual D could use, so it's just a performance difference.

Again, precompiled information doesn't help while you edit code. Long 
term the DMD frontend can be used, but one major problem with using it 
right now is that it bails out if it cannot parse the code, so it won't 
even try to give information about identifiers at the current edit 
location. There is work being done on that, but currently more directed 
towards tools like d-scanner.

> 
> As far as source code is concerned, it happens on any project, so any 
> project should exhibit such problems. Of course, mixin issues will only 
> happen when mixins are used.
> 
> I think any typical use of Visual D tends to demonstrate some issue that 
> needs to be resolved. These are not issues that rarely pop up but are 
> pretty much an every day thing. IMO, there is something fundamentally 
> broke with Visual D or DMD as regard to debugging capabilities. I know 
> some of it is with dmd and the power that be don't care because they 
> don't use modern debugging techniques... so it doesn't effect them. They 
> are probably experienced enough programs and don't write any real apps 
> in D either(exclude utilities are libraries that don't really use a wide 
> variety of things) to have these types of issues... and when they do 
> they either know how to fix them, use their old school debugging 
> methods, or just work through them... none of which is acceptable for me 
> or the average user of D. (and I seriously doubt they have probably even 
> used Visual D, much less for any serious project)
> 
> As a case in point: mixin debugging. This is necessary. It is no 
> different than normal debugging. Where would modern programming be 
> without debuggers? Well, that is where we are at with mixins. We have no 
> real way to debug them. I use them all the time and have to really be 
> careful with what I'm doing and use stupid tricks to debug them. Mainly 
> string mixins, which is far more time consuming than getting an error at 
> some line number. I've learned now that I should use write them as 
> normal runtime functions first and then once they work to make them ctfe.
> 
> But mixin debugging should be easy. After all, it's just a d program 
> inside a d program. dmd compiles it internally, but if dmd had an 
> "internal" debugger then we could debug it and get better results.
> 
> In a since, it's just back tracing anyways.
> 
> dmd -> mixin -> dmd -> mixin output
>     <=                               <=
> 
> If the internal dmd would keep track of whats going on it could map the 
> output line numbers to the input and we could debug the output(which is 
> effectively inserted in to the main source code directly in a "temp" 
> file(dmd may obfuscate that process but that is what effectively is 
> going on))... Visual D could link errors to the original mixin through 
> the line mapping and even open out the generated output in a view for us 
> to see what the mixin outputted.
> 
> 
> Of course, all this is not so simple but it's not so hard... just 
> work(which I guess is the hard part).

There have been several proposals to help debugging mixins, here's one 
of them: https://issues.dlang.org/show_bug.cgi?id=5051

Visual D even highlights *.mixin files as D code...


> 
> My guess is that because dmd was designed a long time ago that it didn't 
> take in to account what might be, and hence we have what we have... 
> which is great on one hand and sorry on the other.
> 
> I would think that one of the most important things that the D 
> foundation would be working on besides bugs in DMD and language design 
> issues is a proper IDE and debugger... but that doesn't seem to be the 
> case.
> 
> Anyways, I've ranted long enough... sorry...