Request: Limit "Fields cannot be injected" to exact classes #3361

Activity

1. tomlau10 commented on Feb 24, 2026

   

   tomlau10

   on Feb 24, 2026

   Contributor

   More actions

   Although I am not maintainer (just a user/contributor), I don't think this would work based on my understanding of how @class works in this language server 😕.

   my understanding

   The inject-field warning is saying that the server cannot allow some code to just modify the fields of a class, as otherwise it cannot do the undefined-field check properly:

   • it must have a way for user to define valid fields
   • and now it is done by @field or actual field/method injection on a variable marked by @class

   ---@class A
   ---@field a string # allowed
   local A = {}
   
   A.x = 1 -- allowed
   function A.y() end -- allowed
   function A:z() -- allowed
       self.field_defined_inside_method = 1 -- allowed, auto injected as `self` is treated as `@class A`
   end
   
   ---@type A
   local a = {}
   a.nope = 2 --> inject-field error, because `local a` is NOT marked by `@class`
   -- its more like an instance of class A only
   print(a.not_define) --> undefined field error, you are accessing a field of class A not registered by the server

   • now think it in another way, if all field injections are allowed, then there is no way to detect a undefined field
     => because ... um all field injections are just allowed 😅
   • as for the (exact) class, it simply limits the class definition to only @field / method definition, but disallow injecting fields inside methods

   ---@class (exact) A
   ---@field a string # allowed
   local A = {}
   
   A.x = 1 -- error
   function A.y() end -- error
   function A:z() -- allowed
       self.field_defined_inside_method = 1 -- error, same case as `A.x = 1` disallowed
   end
   
   ---@type A
   local a = {}
   a.nope = 2 --> error
   print(a.not_define) --> undefined field error

   in reply to the snippet in Reproduction steps

   The problematic code lies in the last part:

   --- @param item Item
   function FlagDebugItem(item)
   	item:Print()  -- with the annotation, this completes. Yay!
   	item.is_cheater = true  -- Warning :( "Fields cannot be injected into the reference of `Item` for `is_cheater`."
   end

   • here item is just an instance variable of Item class
   • so the language server disallows you to inject a field to it
   • even if you "silence" this error, the server actually doesn't inject the is_cheater field to Item class
     => such that you will not see is_cheater in auto complete for another Item object

   -- add the following after your snippet
   ---@type Item
   local a
   a.is_ --> no auto complete for `is_cheater`

   • to property let the server inject is_cheater field, you need to mark the variable with @class

   --- @param item Item
   function FlagDebugItem(item)
   	---@class Item
   	item = item -- now `item` is marked with `@class`, it is treated as a "class" variable and allowed for injection
   	item:Print()  -- with the annotation, this completes. Yay!
   	item.is_cheater = true  -- now this is properly injected
   end
   
   ---@type Item
   local a
   a.is_ --> now you can see `is_cheater` as completion

   • i know this ---@class Item; item = item line is a bit dumb 🤦‍♂️
   • but thats the workaround that I used 😂 to let the server properly inject a field in these situation

   ---

   I understand that people may not want to add (exact) all over their codebase

   As explained from above, adding (exact) is totally a different thing 🙅‍♂️
   Because it will disallow fields that are defined just inside method, like in you case:

   function Item:new(id, category)
   	self.id = id
   	self.category = category
   	self.count = 0
   end

   => if you add (exact) then these fields will not be injected
   => you will then have to write them using @field before you can use these fields
   => which loses all the benefits of auto injection IMO
2. idbrii commented on Mar 7, 2026

   

   idbrii

   on Mar 7, 2026

   Author

   More actions

   The inject-field warning is saying that the server cannot allow some code to just modify the fields of a class, as otherwise it cannot do the undefined-field check properly

   That seems like an understanding based on how it behaves and not the code? If it knows when fields are injected into a class (because it warns), then it could add those fields to the class definition and have a list of fields that can be accessed.

   as for the (exact) class, it simply limits the class definition to only @field / method definition, but disallow injecting fields inside methods

   If that's true, the docs should make that clearer. (The definition sounds like definition of the Lua object, not the annotation.) Regardless, I think we should preserve the ability to warn about an exact class.