No autocompletion or tool tip for a public property of an instance

bgrommes

The following reference in code, where columnDefinition is a local variable containing an instance of class MemoryTableColumn, gives me both autocomplete help and, after entered, a tool tip on hover for the class definition.
But I get neither for the Integer StartingOffset property, which is a straight-up public property (not read only or computed). Basically a bog-simple situation with nothing special about it that I can think of.

columnDefinition.StartingOffset

However, StartingOffset doesn't trouble Analyser or fail to compile (or work).

Here's another edge case that's not working, where source is a variable of type Object:

WriteString(columnDefinition, (Integer(source)).ToString(), target)

Here, I'm not getting autocomplete or a tool tip on ToString(). I don't mind the extra set of parens really, I'd have to do the same thing in C# -- ((int)source).ToString(), it is just that when I'm being so helpful to the IDE, why does it ignore me (sob).

Garry

Thanks for the detailed report. I've reproduced both of these, and they're both real bugs in the editor's code-completion/hover resolver. The compiler is fine, which is exactly why the code analyses and runs without complaint: autocomplete and tool tips use their own expression resolver, and it's missing two things your code exercises. I've logged them separately:

The cast case is unconditional: any member access on a cast receiver, like (Integer(source)).ToString(), loses both autocomplete and the hover tool tip. The resolver doesn't currently understand cast expressions as receivers, parenthesised or not. Your extra set of parens is correct Objo (same as C#) and not the problem, the IDE just isn't looking inside them.

For columnDefinition.StartingOffset, the simple case works here, so something about the type's visibility is the trigger. The mechanism I've confirmed: if MemoryTableColumn is declared inside a Namespace, or made visible by an Import statement, the compiler happily accepts the short name — but the completion resolver doesn't model namespace/Import scopes yet, so it can't work out the type of columnDefinition and gives you nothing after the dot. Could you confirm whether that class sits in a namespace, or whether that method's file has an Import at the top? That would pin it down to exactly what I've reproduced on my end.

Both are on the fix list for a future release — follow the Feedback items above for progress.

bgrommes

Garry Could you confirm whether that class sits in a namespace, or whether that method's file has an Import at the top?

That class is in a Module, and the code that's referencing it is in the same Module. At this point I'm not using Import or namespaces.

Garry

Thanks. That pins it down, and it's a helpful answer: your case turned out to be a third variant of the same underlying gap. As well as namespaces and Import, the compiler also accepts a short name for a type declared in the same Module as the code referencing it and the editor's autocomplete/hover resolver wasn't modelling module scope either. Same family, same symptom. The code compiles and runs fine, but the IDE can't work out the type after the dot, so it offers nothing. There's nothing wrong with your project structure; the language fully supports classes inside a module, the editor just wasn't keeping up.

The good news is that this is already covered. The fix for No autocomplete or tool tips for types referenced through a namespace or Import rebuilds the resolver's scope model to follow the compiler's full name-resolution order. I reproduced your exact setup against the fixed build and both autocomplete and the hover tool tip work for the public property. So no separate item is needed: yours ships with that same fix in the next release.

The cast case (No autocomplete or tool tips for members accessed on a cast expression) is still on the fix list and will follow separately.

bgrommes

Garry Muchas gracias and merci!