Fix all non-bug lints. Switch to let statements.

[JohnHeitmann]

After these changes there is only one error report remaining from the linter, and that appears to be a real bug.

The first commit has all the non-trivial changes. The second is a mechanical s/var/let/.

cc: #51735

[JohnHeitmann]

I'm embarrassed to admit I can't find where those unknown origin globals are coming from. If you can point out their source I'll update those docs.

[JohnHeitmann]

Ah, right after submit I found it. Unique DOM ids are automatically added to window.

[Centril]

r? @QuietMisdreavus

[bors]

☔ The latest upstream changes (presumably #57108) made this pull request unmergeable. Please resolve the merge conflicts.

[Centril]

@JohnHeitmann Please avoid merge commits; we'd prefer rebasing instead. :)

[JohnHeitmann]

Sorry about that. I force-pushed a clean rebase. I kept the two separate commits to keep the more interesting changes apart from the search and replace change.

[bors]

☔ The latest upstream changes (presumably #57006) made this pull request unmergeable. Please resolve the merge conflicts.

[QuietMisdreavus]

cc @GuillaumeGomez for changes to JS

Do we run eslint in CI? Is it particularly time-intensive? @rust-lang/infra Would it be possible to slot it into one of our existing builders?

[kennytm]

Note: https://caniuse.com/#search=let

---

@QuietMisdreavus

Do we run eslint in CI?

I can't find anything about eslint in this repo 🙃. If we could make it runnable via ./x.py test ..., we could add this to mingw-check or x86_64-unknown-linux-gnu (depending on whether a bootstrap is needed).

[JohnHeitmann]

While it runs fast, eslint is a node app. Another thread made it sound like node was a challenging dependency to impose upon some distros, so I assumed this would be a best-effort tool used by humans.

If node is ok in the build after all I could take a look at adding this to CI.

[kennytm]

We already depend on nodejs to run the src/test/rustdoc-js tests (the test is skipped if nodejs is missing).

[JohnHeitmann]

This is my plan for moving this forward. Please steer me if this looks like the wrong direction:

1. Implement a build.config.eslint setting in https://github.com/rust-lang/rust/blob/master/src/bootstrap/test.rs
2. Run eslint in the rustdoc-js test target
3. Update the test travis config to install eslint via npm like clippy does with remark: https://github.com/rust-lang/rust-clippy/blob/39bd84494f4a9b40f2e3b38416a91d52d5c4738b/.travis.yml#L29
4. Somehow test the travis build. Do I just need to set up my own travis instance and it'll just work? Let me know if there are mines here.
5. Fix the build blockers after we see the build is properly blocked (there's one unfixed bug the lint catches).

[QuietMisdreavus]

Somehow test the travis build. Do I just need to set up my own travis instance and it'll just work? Let me know if there are mines here.

If you need to run a specific travis instance on your PR without trying to merge it, you can edit the travis.yml file to run a specific builder on pull requests as well instead of just the "auto" branch. (I'd recommend also renaming the PR here to add "WIP" to it so bors doesn't accidentally merge the travis configuration change.)

[JohnHeitmann]

I just did something horribly wrong in my git workflow on this branch and I'm not confident I can back it out without tagging more unrelated issues. Closing this out to start from a fresh branch.