This might be a bad idea, especially on the webidl side. However, we started talking about the idea that modelines are a lint error (https://github.com/servo/servo/issues/10719), and these changes would be required before enabling a modeline lint.
If it bitrots, it's easy to recreate with
```
find * -type f -exec sed '/- Mode:/d' -i {} +
find * -type f -exec sed '/ vim:/d' -i {} +
git checkout -- python/tidy/servo_tidy/tidy.py
git checkout -- python/tidy/servo_tidy_tests/spec.webidl
git commit -a
```
Source-Repo: https://github.com/servo/servo
Source-Revision: dff217c2e3ff0b77eeebf62d36c2bf57c044cf14
Currently, there are a few linting functions that only run on certain
filetypes (determined by the file extension). Prior to this commit, the
special cases were handled in a parent function with a conditional. This
commit changes the system so each linting function gets passed a
filename so the function can determine whether it should run or not
based on the file extension.
I also refactored flake8 linting slightly. From what I've read so far of
the code, flake8 itself will only print the results directly to stdout
(though the linter would report the quantity of errors detected).
Prior to this commit, we would let flake8 print directly to stdout and
just determine if there were >0 errors reported. This commit (sort of
hackily) temporarily captures stdout when we call flake8 so we can do
what we want with the output, allowing us to `yield` the line number
and message like we do with the other linting functions.
In my opinion, both of these changes isolate specific behaviors/checks
into their respective linting functions instead of having them handled
at a more global level.
In addition to the changes above:
* The whitespace linter now runs on WebIDL and TOML files
* The license header linter now runs on WebIDL files
Source-Repo: https://github.com/servo/servo
Source-Revision: 7c8922c0c39616559b580b4a363ebe2a8c6b3ba8
Didn't touch mozjs or rust-mozjs because implementing that in the code generator didn't seem too easy. I'm using the same workaround that the TextDecoder does.
Using the OsRng should be the right choice here? As the OS keeps state for us we wouldn't need to have a global rng instance to keep around.
Fixes#4666.
Source-Repo: https://github.com/servo/servo
Source-Revision: c0222628264423a67bf98775be83dcf2f85211ab
