Unexpected Attribute in tfvars

[theherk]

Language Server Version

0.34.3+Homebrew

Terraform Version

Terraform v1.6.6 on darwin_arm64

Client Version

NVIM v0.10.1

Terraform Configuration

variable "cname_records" {
  type        = map(string)
  description = "Map of CNAME records, where key is the domain and value is the record value."
}

cname_records = {
  "_cea53b5cd872a2d2d966a339ae031d59.foo.no." = "_8e50420392efe6ae6720f03fd2acd445.nhqijqilxf.acm-validations.aws."
}

Steps to Reproduce

1. Define the variable in variables.tf.
2. Set the variable in terraform.tfvars.

Expected Behavior

I expect not to get any errors, as this is a correct and working configuration.

Actual Behavior

Receive the error Unexpected attribute: An attribute named "cname_records" is not expected here.

Gist

No response

Workarounds

No response

References

No response

Help Wanted

• [ ] I'm interested in contributing a fix myself

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[tomlau10]

Maybe this can fix a related issue for requesting to differentiate between local and global variables as well: https://github.com/LuaLS/lua-language-server/issues/2880, since in this PR it uses different colors for them by default.

---

I just checked out this PR locally, I notice that now the global tokens are changed to variable.definition type instead of variable.global, and have a different default color.

However in the theme that I used (One Dark Pro), the default color of variable.definition is the same of class and self, so now they just collided with another variable type instead of local variables. 😅

Is this the expected outcome? 🤔 Since currently self is also of type variable.definition, that means I CANNOT use a rule to differentiate between self and global variable... In the case before when they are variable.global, I can still use a rule to distinguish them, as mentioned here: https://github.com/LuaLS/lua-language-server/issues/2880#issuecomment-2388181534

---

edit: Oh~ I just found that you already proposed to change self to variable.static or variable.readonly in your original issue 👀

"variable.definition" is used in self, so if it will be accepted the suggestion is change self to "variable.static" or "variable.readonly"

[comedinha]

I think readonly is a good setting to use too. And you can diff from the self variable. I will change the PR.

I use the theme "Dark Modern" and the colors will be

[tomlau10]

In the One Dark Pro theme that I used, both readonly and definition have the same color. 🙈 And semantically, a global variable doesn't mean readonly. 🤔 Moreover variable.readonly will collide with _ENV and variable with <const> keyword

A = {}          -- `A` is `variable.readonly`
local a<const>  -- `a` is `variable.readonly`
print(a)        -- `a` is `variable.readonly`
_ENV = nil      -- `_ENV` is `variable.readonly`

=> they all have same colors now and no way to distinguish them 😇

---

The TokenModifier global isn't is a default token to vscode documentation (doc).

I understand global modifier is non standard, but after some googling I found out that vscode-cpptools is also using global modifier for global variables: https://github.com/microsoft/vscode-cpptools/issues/4992 Only with a new global modifier, then we are specifically theme a global variable with its own color 🤔

Furthermore I just read the vscode doc you provided, seems an extension can create a custom textmate scope mappings for fallback theming: https://code.visualstudio.com/api/language-extensions/semantic-highlight-guide#custom-textmate-scope-mappings Maybe another approach is to map variable.global to variable.readonly something like that in the vscode-lua extension? https://github.com/LuaLS/vscode-lua/blob/34c70bbda7de10664e2681ccd1f08940ebc73d34/package.json#L3377-L3379

In this way:

• luals (the server itself) can provide the most accurate modifier type (global)
• users (like me) can theme variable.global specifically
• and fallback type variable.readonly is provided, such that normal users by default already have different colors for global and local variables 😄

@comedinha

[tomlau10]

Hi, I just tested modifying the semanticTokenScopes in package.json of vscode-lua extension locally

• by changing the fallback value of variable.global from variable.global.lua to variable.other.constant.lua https://github.com/LuaLS/vscode-lua/blob/34c70bbda7de10664e2681ccd1f08940ebc73d34/package.json#L3377-L3379

					"variable.global": [
						"variable.other.constant.lua"
					],

• it can achieve the same result as using color as constants, while preserving the variable.global modifier

• And I can still use custom variable.global:lua rule to theme it specifically, without modifying the color of other constants:

    "editor.semanticTokenColorCustomizations": {
        "[One Dark*]": {
            "rules": {
                "variable.global:lua": "#E06C75",
            },
        },
    },

---

In short I believe this would be a better approach for defaulting the color of global variables, rather than directly changing its token type sent from LuaLS 👀

---

edit: after doing some git blame on vscode-lua repo, this variable.global is added by author purposely 🤔

• originally he used variable.static https://github.com/LuaLS/vscode-lua/commit/dd88c4437c6791f43b39a68b14c7508c95f3ea06
• and later he changed to variable.global https://github.com/LuaLS/vscode-lua/commit/cabcdeb8948fdb74f677d7faf3b957726e657046
• With this fact, I don't think author would like to rollback the modifier sent from LuaLS to static or readonly. And modifying the fallback textmate scope in the vscode extension's side would be a better approach.

[CppCXY]

Rendering code is not limited to semantic tokens; in fact, it can also be done using a custom protocol in VSCode with vscode.TextEditor.setDecorations. This rendering can override the limitations of the theme itself, providing more flexibility and stronger visual effects.

[comedinha]

Rendering code is not limited to semantic tokens; in fact, it can also be done using a custom protocol in VSCode with vscode.TextEditor.setDecorations. This rendering can override the limitations of the theme itself, providing more flexibility and stronger visual effects.

I will check this way. I work with many people who won't configure VS Code by themselves. This change needs to be global for me because I can't teach everyone and new coworkers how to configure their editor. They just open the folder, and all LuaLS settings are automatically set.