Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WASM] Enabled strict mode on all JS files #54011

Merged
merged 2 commits into from
Sep 14, 2021

Conversation

Daniel-Genkin
Copy link
Contributor

This PR adds the "use strict" annotation to all JS files (including dotnet.js via the emcc STRICT_JS flag).

Why is this needed?

This annotation signals to the JS engine that the file should be run in strict mode which throws errors/exceptions when some looser features of JS are used (for example using undeclared variables). This is also required to ease the eventual NodeJS support that I am working on adding to wasm.

What's changed

Basically every file ending with .js will have the "use strict" annotation on the first line. This is mostly done manually with the only exception being the dotnet.js file as it is automatically generated. For that I used the STRICT_JS emcc flag.

Other minor changes

  • Some of the files in the runtime folder where a mix of tabs and spaces. I changed them to be all tabs (there were more tabs than spaces).
  • There were a few unused variables that I removed and a few that I marked with comments

@ghost
Copy link

ghost commented Jun 10, 2021

Tagging subscribers to this area: @CoffeeFlux
See info in area-owners.md if you want to be subscribed.

Issue Details

This PR adds the "use strict" annotation to all JS files (including dotnet.js via the emcc STRICT_JS flag).

Why is this needed?

This annotation signals to the JS engine that the file should be run in strict mode which throws errors/exceptions when some looser features of JS are used (for example using undeclared variables). This is also required to ease the eventual NodeJS support that I am working on adding to wasm.

What's changed

Basically every file ending with .js will have the "use strict" annotation on the first line. This is mostly done manually with the only exception being the dotnet.js file as it is automatically generated. For that I used the STRICT_JS emcc flag.

Other minor changes

  • Some of the files in the runtime folder where a mix of tabs and spaces. I changed them to be all tabs (there were more tabs than spaces).
  • There were a few unused variables that I removed and a few that I marked with comments
Author: Daniel-Genkin
Assignees: -
Labels:

area-VM-meta-mono

Milestone: -

@thaystg thaystg added the arch-wasm WebAssembly architecture label Jun 10, 2021
@ghost
Copy link

ghost commented Jun 10, 2021

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

This PR adds the "use strict" annotation to all JS files (including dotnet.js via the emcc STRICT_JS flag).

Why is this needed?

This annotation signals to the JS engine that the file should be run in strict mode which throws errors/exceptions when some looser features of JS are used (for example using undeclared variables). This is also required to ease the eventual NodeJS support that I am working on adding to wasm.

What's changed

Basically every file ending with .js will have the "use strict" annotation on the first line. This is mostly done manually with the only exception being the dotnet.js file as it is automatically generated. For that I used the STRICT_JS emcc flag.

Other minor changes

  • Some of the files in the runtime folder where a mix of tabs and spaces. I changed them to be all tabs (there were more tabs than spaces).
  • There were a few unused variables that I removed and a few that I marked with comments
Author: Daniel-Genkin
Assignees: -
Labels:

arch-wasm, area-VM-meta-mono

Milestone: -

@pavelsavara
Copy link
Member

Could you please change var to const everywhere where we do not re-assign or let otherwise ?
Thank you!

@Daniel-Genkin
Copy link
Contributor Author

Daniel-Genkin commented Jun 14, 2021

Could you please change var to const everywhere where we do not re-assign or let otherwise ?
Thank you!

Good idea! However it is kind of parallel to this PR, so I'll make a new PR for this after this one is completed.

@Daniel-Genkin Daniel-Genkin marked this pull request as ready for review June 14, 2021 18:58
@thaystg thaystg requested review from lewing, kg, radical and thaystg June 14, 2021 18:59
src/mono/wasm/runtime-test.js Outdated Show resolved Hide resolved
@kg
Copy link
Member

kg commented Jun 14, 2021

This generally seems fine, but I think mixing all these whitespace changes in might be a mistake. It clutters the git blame and makes it unclear what this PR actually did or didn't do.

@Daniel-Genkin
Copy link
Contributor Author

Daniel-Genkin commented Jun 14, 2021

@kg Should they be removed? I just converted all the files in runtime to use tabs instead of spaces for consistency since I was already making such syntax changes (see the other minor changes section in the description). Before this, some files had a mix of spaces and tabs.

Copy link
Member

@kg kg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kg Should they be removed? I just converted all the files in runtime to use tabs instead of spaces for consistency since I was already making such syntax changes (see the other minor changes section in the description). Before this, some files had a mix of spaces and tabs.

I don't know if we have a policy for that in /runtime. It usually makes diffs and blame harder to review, but github has a 'hide whitespace changes' option so maybe it's fine.

src/mono/wasm/runtime/library_mono.js Outdated Show resolved Hide resolved
src/mono/wasm/runtime/library_mono.js Outdated Show resolved Hide resolved
src/mono/wasm/runtime/library_mono.js Outdated Show resolved Hide resolved
@kg
Copy link
Member

kg commented Jun 14, 2021

Other than my previous comments I'm happy with this PR, thanks for doing it. I can't give it a green check yet though because if it landed it would block the marshaler PR, so I want to make sure that gets in first unless we decide not to land it at all

@Daniel-Genkin
Copy link
Contributor Author

Other than my previous comments I'm happy with this PR, thanks for doing it. I can't give it a green check yet though because if it landed it would block the marshaler PR, so I want to make sure that gets in first unless we decide not to land it at all

Ok. Thanks for your review. That makes sense. Do you think the marshaler PR will be done sometime soon?

@kg
Copy link
Member

kg commented Jun 14, 2021

Other than my previous comments I'm happy with this PR, thanks for doing it. I can't give it a green check yet though because if it landed it would block the marshaler PR, so I want to make sure that gets in first unless we decide not to land it at all

Ok. Thanks for your review. That makes sense. Do you think the marshaler PR will be done sometime soon?

I'm working on figuring that out as we speak. Sorry for delaying your work with this

@Daniel-Genkin
Copy link
Contributor Author

I'm working on figuring that out as we speak. Sorry for delaying your work with this

Haha ok sounds good. I'll work on some other tasks for now then. Thanks again

@lewing
Copy link
Member

lewing commented Jun 15, 2021

I don't see any dotnet_support.js changes?

@Daniel-Genkin
Copy link
Contributor Author

I don't see any dotnet_support.js changes?

I didn't see anything that wasn't compliant with strict mode. Do you see something? Primarily, I was looking for undeclared variables or other strict mode related errors.

lewing
lewing previously requested changes Jun 15, 2021
Copy link
Member

@lewing lewing left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good, a couple of comments and one issue.

src/mono/wasm/runtime-test.js Outdated Show resolved Hide resolved
@Daniel-Genkin Daniel-Genkin mentioned this pull request Jun 22, 2021
9 tasks
@Daniel-Genkin
Copy link
Contributor Author

Daniel-Genkin commented Jun 23, 2021

Note that this PR should be merged after #54281 to minimize merge conflicts and to avoid mixing them up.
Update: #54281 has been closed but this PR is still waiting on the marshaler one (#47640)

@kg kg added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Jun 23, 2021
@marek-safar
Copy link
Contributor

What is the plan with this PR?

@kg
Copy link
Member

kg commented Jul 19, 2021

If we land it all the marshaler and invoke stuff will probably have to be rewritten to rebase it. Otherwise the PR looks great

@Daniel-Genkin
Copy link
Contributor Author

Daniel-Genkin commented Jul 19, 2021

Yes I left this pending while Katelyn works on the marshaler one. It has not been forgotten :)

@terrajobst terrajobst added the community-contribution Indicates that the PR has been added by a community member label Jul 19, 2021
@pavelsavara pavelsavara removed the community-contribution Indicates that the PR has been added by a community member label Jul 26, 2021
Copy link
Member

@pavelsavara pavelsavara left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, what do you think @kg ?

@kg
Copy link
Member

kg commented Jul 29, 2021

LGTM, what do you think @kg ?

My previous opinion (it's great) holds, but we should come to a firm decision w/Larry or other involved decision-makers that we're going to abandon the invoke and/or marshaler PRs before we land it, since that's what landing it implies.

@pavelsavara
Copy link
Member

I understood Larry said that we are not going to land it in 6.0
Also I think it only implies we would have to eventually re-base it later, not necessarily abandon it.
And we are already also doing lot of other stuff in the codebase which has similar effect as this PR.
Let's not stop the world ;-) My 2c

@pavelsavara pavelsavara requested a review from lewing August 17, 2021 10:50
@pavelsavara pavelsavara force-pushed the wasm-use-strict branch 2 times, most recently from 29d79bb to 822f1e2 Compare August 26, 2021 10:54
@pavelsavara pavelsavara removed the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Aug 26, 2021
@pavelsavara
Copy link
Member

@kg @lewing I would like to merge it later today, please let me know if you have any pending concerns.

author: Daniel Genkin
squashed, rebased
@pavelsavara
Copy link
Member

Failure is #58812 and other wasm unrelated failures

@pavelsavara pavelsavara merged commit 55622ab into dotnet:main Sep 14, 2021
@ghost ghost locked as resolved and limited conversation to collaborators Nov 3, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-wasm WebAssembly architecture
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants