Script Editor should omit unknown global warnings based on what I set the function environment to

StarIitNova · August 22, 2020, 12:30pm

As a Roblox developer, it can get very annoying when using setfenv() to modify globals.

I believe that the roblox script editor should adapt it’s globals to what the current environment is.
If an object is not in a predefined global or if it was changed maybe it gets the default global color.

What I’m saying is, whenever I use lets say setfenv(1, {__ver = "version 1.0.0"}) I don’t want to see a warning underline for when I run print(__ver) because when I press run in studio it seems to work fine. Of course I’m not just setting the environment to a table with one descendant, I’m setting the environment to getfenv(1) with some edits.

Honestly, an adaptive to setfenv script editor would be amazing. I mainly want this because I am working on a framework that sets custom globals. I don’t want users of the framework to think that there code has an error and immediately look for a fix when there isn’t an error. I do hope at some point it is added or is being worked on currently.

Webmotion · May 21, 2023, 5:08pm

I know this post is from a while back but this would also be of great use to me.

Is something like this possible or would the implementation of this have any negative implications?

metatablecatmaid · May 21, 2023, 5:57pm

CC @Webmotion

getfenv and setfenv are deprecated

github.com

Roblox/luau/blob/master/rfcs/deprecate-getfenv-setfenv.md

# Deprecate getfenv/setfenv

## Summary

Mark getfenv/setfenv as deprecated

## Motivation

getfenv and setfenv are problematic for a host of reasons:

- They allow uncontrolled mutation of global environment, which results in deoptimization; various important performance features
like builtin calls or imports are disabled when these functions are used.
- Because of the uncontrolled mutation code that uses getfenv/setfenv can't be typechecked correctly; in particular, injecting new
globals is going to produce "unknown globals" warnings, and modifying existing globals can trivially violate soundness wrt type
checking
- While these functions can be used for good (once you ignore the issues above), such as custom module systems, statistically speaking
they are mostly used to obfuscate code to hide malicious intent.

## Design

This file has been truncated. show original

Webmotion · May 21, 2023, 6:16pm

They are not marked as deprecated in the Roblox Developer documentation nor in script editor autocomplete. As otherwise stated in that document, the linter does not emit warnings or any deprecation notice for these functions.

Edit: I’m aware these functions were removed from Lua in version 5.2 due to environment changes so it would be understandable for these functions to be deprecated eventually. However, the Roblox documentation and script editor autocomplete did not make me aware of this.

StarIitNova · May 22, 2023, 12:58am

Weird seeing this get some “traction” but anyways:
getfenv and setfenv are deprecated as metatablecat said, although are still “usable”

With that out of the way, the best way to omit the warnings/errors is probably to not use them at all. They also create a sort of “hiding place” for variables and functions which is not only bad for stuff like toolbox models and dangerous scripts, but also poses difficulty to the developer using it (ex: trying to find where a variable is because it might be put into the environment in one of many scripts)
You can simulate the creation of “global” variables in multiple ways, usually if they’re static store them in a module script, otherwise you can use value objects (ex leaderstats) or events. These methods also make it easier to find where they are stored

Now if you do still wish to use these, you can use something like Rojo with VSCode to omit the warnings.

The original reason I posted this was because I was making something like moonscript or roblox-ts and used the setfenv function to be able to make that possible, if you’re looking to use some other language that translates into Lua I’d probably go with using Rojo

From my point of view: I would not use setfenv or getfenv, it ends up just being more difficult to read when in theory with some extra variables can get away with something similar.

I’ll probably mark this as the answer for now unless for some reason this feature request is fulfilled, although it probably wont be.

EDIT: note this is not an actual “solution” to the problem but more so a workaround, but I do deem the workarounds as much better and safer than using setfenv and getfenv

system · June 5, 2023, 12:58am

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.