Cannot use "const/static string Name" in a class with 'use strict' mode enabled on Firefox

[theoutlander]

Encountered this a few months ago and just realized I didn't report it.

In S#, I have something like:

public class SomeClass 
{
     public const string Name = "blah";
     public const string Foo = "Bar";
}

In Firefox, while using strict mode, the application throws an error when a const/static string is initialized stating that it is a read-only property. The issue I think is two fold:

1. An exported class seems to have an internal attribute called 'name'. So in the above example (without the name field), let's say S# exported the class as Namespace$SomeClass. It means that I can type Namespace$SomeClass.name and it will return Namespace$SomeClass which is really the class name.
2. In strict mode, when the above example is used with the name field, it is initialized to "blah", which will throw an error as it already exists and it is a read-only field in Javascript. I don't know how Javascript implements read-only properties, but it seems to be the case and it makes sense. I haven't seen that problem in IE/Chrome.

What I'm thinking is that we might need a list of reserved keywords for constant/static attribute names.

[nikhilk]

I'd hate to lose "Name" to a reserved word list... though maybe you're suggesting only preventing its use for a static/const. That would require bit more work, whereas adding to the global reserved list for all identifiers is much more straightforward.

The other question is should it in fact be reserved, or rather should it be transformed into a safe name. I sort of prefer that, as it would allow using "Name" in the c# source. Then the question becomes should it be automatic (and if so what is a good transformed name, given it might be intended as a public surface area of an API) or should it be explicitly specified by the developer via [ScriptName].

[theoutlander]

I was thinking of a static/const reserved list for coded classes instead of transforming the field name. If you think about it, in strict mode you won't be allowed to create an attribute called name on the exported object so it makes sense to restrict the user in S#.

However, one additional thing to consider is that the module loader might be creating the name attribute on the exported/required object (I haven't tried to trace where it gets created). Since S# follows the AMD pattern, it would make sense to add 'name' (and anything else) to the reserved list.

I'm not sure how involved this is, but I can take a stab at it if you can point me in the right direction. Might also be a good introduction for me into making changes on the compiler side of things. I've wanted to implement a few things, but just don't know where to start.

[nikhilk]

The module object is a vanilla object, and not a function/type, so name there doesn't conflict.

In thinking more about reserving "Name" but only for statics/consts, this is actually quite straightforward to implement. Rather than adding to the global reserved words list, we just need to add a rule right after the check against the global reserved words list that is happening around https://github.com/nikhilk/scriptsharp/blob/cc/src/Core/Compiler/Validator/CustomTypeNodeValidator.cs#L202

See if that provides enough direction to try implementing it...

[theoutlander]

Thanks. I'm trying to step through the code, but it states that the code is optimized when I try to view variables. I enabled debug mode with optimization off, but it still gives the same message. I've re-installed the VSIX after rebuilding and it breaks into the #if DEBUG code, but I still can't get it to show anything. Is there anything else I need to change or anything special that you do?

[nikhilk]

There are a few ways to debug...

1. Perhaps the simplest is to open the test solution and debug through a test.
2. Debug ssc.exe instead. You can setup appropriate debug settings in VS for the project and F5 through that. Alternatively with debug build ssc.exe can be run with a /attach commandline parameter causing it to issue a debug.fail early on in the compiler before anything meaningful has happened, at which point you can attach a debugger as well.
3. Open a second instance of VS, and attach to the first instance of VS running the script# compiler. To get debug build of ScriptSharp.dll loaded, you'll need to update the ScriptSharp.dll and ScriptSharp.Build.dll in the expanded out nuget package... so it requires creating a Script# project, closing VS, and copying over ScriptSharp.dll and then restarting VS (and do so every time you change things). So this requires some prep steps. I usually do this if I have to debug the msbuild task.

Unless you've changed things, the VSIX and nuget packages are only generated for release builds.