IntelliSense/autocomplete doesn't work properly inside object literals

[ArturAbdullin]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.66.2 (system setup)
• OS Version: Microsoft Windows Version 21H1 (OS Build 19043.1526)

Steps to Reproduce:

1. Create a new object using object literal with two or more properties and a method:
   let obj = { x: 10, y: [1], fun: function () {}
2. Now, inside the method, addressing to the properties using this keyword is recognised by the IntelliSense/autocomplete.
   this. - results in
   
3. Change the value of a property inside the method, for instance
   let obj = { x: 10, y: [1], fun: function () {this.x = 5;}}
4. Now, only addressing to the property x is recognised by the IntelliSense/autocomplete:
   
   Even though y property is an array, IntelliSense won't show its methods and properties:
   

System info

CPUs	Intel(R) Core(TM) i5-6600 CPU @ 3.30GHz (4 x 3312)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)
Memory (System)	15.89GB (4.73GB free)
Process Argv	...\vscode issue --crash-reporter-id 85c4d140-e4d5-49f1-8a5a-495612b0049f
Screen Reader	no
VM	0%

Extensions: none

A/B experiment info

vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyl392:30443607
pythontb:30283811
pythonvspyt551:30345470
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscorecescf:30445987
pythondataviewer:30285071
vscod805cf:30301675
pythonvspyt200:30340761
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593:30376534
vsc1dst:30438360
pythonvs932:30410667
wslgetstarted:30449410
pythonvsnew555:30457759
vscscmwlcmt:30465135
cppdebugcf:30475217

[andrewbranch]

@sandersn not sure if this is a known limitation—can you help triage?

[sandersn]

I can't remember, but it's surprising and undesirable enough that I want to double-check.

Initial investigation shows that the problem is in the checker, not completions. Compare the type of this in fun vs f2:

export { }
let obj = {
  x: 10,
  y: [1],
  fun: function() {
    this.x = 1
    this/*1*/
  },
  f2: function() {
    this.x
    this/*2*/
  }
}

In fun, it's this: this; in f2 it's this: { x: number, y: number[], fun: typeof fun, f2: () => void }

I'm pretty sure that the assignment to this.x incorrectly makes the checker treat fun as its own class, instead of a method on obj.

[jakebailey]

Is it possible to write a class and export it via CommonJS in such a way that we can't actually figure out if it's supposed to be a class or object?

e.g: Playground Link

module.exports = {
    SomeClass: function() {
        this.x = 1;
    }
}

const a = new module.exports.SomeClass()
console.log(a.x)

[andrewbranch]

I would think you might need /** @class */ to disambiguate, but I could be way oversimplifying things.

[andrewbranch]

In fact, IIRC, it used to be the case that all classy-functions needed /** @class */ to get their own this scope. Later I think we added some heuristic about declarations to this properties that made that unnecessary. But in a context like you wrote where the this could be seen as ambiguous, the @class tag may still be useful.