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
If there's an error in the command-line arguments for `mach build`, we should print it before starting a (potentially) long bootstrap process, not after.
r? @larsbergstrom or @frewsxcv
Source-Repo: https://github.com/servo/servo
Source-Revision: c7f73ebc2938e5dc67a10238cac9fc10f95e2f5f
Implement HSTS (preload-only) servo/servo#6105
* Downloads the HSTS preload list from the chromium repo (same as gecko), then convert it to a list appropriate for servo.
* Reads the preload list when creating a resource task, and implements STS for those domains.
Still todo:
* Read Strict-Transport-Security headers from servers and add details to the in-memory HSTS list. (note: this requires hyper or servo to implement an STS header struct. Hyper seems like the appropriate location, so I will create an issue/PR there soon). The work for this is nearly done with the exception of adding a new ControlMsg and the new header.
* Persist HSTS list to disk with known hosts (perhaps a different issue should be raised for this?)
Source-Repo: https://github.com/servo/servo
Source-Revision: ab3d6c472d409c1602c873dcdcb495a7fec9d4b0
This checks every .toml file for an asterisk and prints an error if found.
Source-Repo: https://github.com/servo/servo
Source-Revision: 58e9bc6583b6ebbeb27e3b28a6b271ee48cd695a
Recently, I found myself reading through the Python codegen scripts that
live in 'components/script/dom/bindings/*' and noticed that there were
many tidy violations: unnecessary semicolons, weird spacing, unused
variables, lack of license headers, etc. Considering these files are now
living in our tree and mostly maintained directly by contributors of
Servo (as opposed to being from upstream), I feel these files should not
be excluded from our normal tidy process. This commit removes the
blacklist on these files and fixes all tidy violations.
I added these subdirectories to the blacklist because they appear to be
maintained upstream somewhere else:
* "components/script/dom/bindings/codegen/parser/*",
* "components/script/dom/bindings/codegen/ply/*",
Also, I added a few '# noqa' comments which tells us to ignore the
flake8 errors for that line; they are mostly for unused/undefined
variables. I chose to ignore these (instead of fixing them) to make the
work for this commit simpler for me.
Source-Repo: https://github.com/servo/servo
Source-Revision: 2d2a340633dcc73e458a8454b78e26ba93511d37
notify_darwin should trap import errors and should provide the useful package name for the user to install. Fix for issue #6479.
Source-Repo: https://github.com/servo/servo
Source-Revision: 3df35c2f42d7224560837a9ef63400e0e16829bf
> Here it is.
>
> ~~There's two major things that are unfinished here:~~
> - ~~Dealing with the unroot_must_root lint. I'm not sure about the value of this lint with the new rooting API.~~ Done.
> - ~~Updating the Cargo.locks to point to the new SM and SM binding.~~ Done.
>
> I also included my fixes for the rust update, but these will disappear in a rebase. A rust update is necessary to support calling `Drop` on `Heap<T>` correctly when `Heap<T>` is inside a `Rc<T>`. Otherwise `&self` points to the wrong location.
>
> Incremental GC is disabled here. I'm not sure how to deal with the incremental barriers so that's left for later.
>
> Generational GC works. SM doesn't work without it.
>
> The biggest change here is to the rooting API. `Root` was made movable, and `Temporary` and `JSRef` was removed. Movable `Root`s means there's no need for `Temporary`, and `JSRef`s aren't needed generally since it can be assumed that being able to obtain a reference to a dom object means it's already rooted. References have their lifetime bound to the Roots that provided them. DOM objects that haven't passed through `reflect_dom_object` don't need to be rooted, and DOM objects that have passed through `reflect_dom_object` can't be obtained without being rooted through `native_from_reflector_jsmanaged` or `JS::<T>::root()`.
>
> Support for `Heap<T>` ended up messier than I expected. It's split into two commits, but only because it's a bit difficult to fold them together. Supporting `Heap<T>` properly requires that that `Heap::<T>::set()` be called on something that won't move. I removed the Copy and Clone trait from `Heap<T>` so `Cell` can't hold `Heap<T>` - only `UnsafeCell` can hold it.
>
> `CallbackObject` is a bit tricky - I moved all callbacks into `Rc<T>` in order to make sure that the pointer inside to a `*mut JSObject` doesn't move. This is necessary for supporting `Heap<T>`.
>
> `RootedCollectionSet` is very general purpose now. Anything with `JSTraceable` can be rooted by `RootedCollectionSet`/`RootedTraceable`. Right now, `RootedTraceable` is only used to hold down dom objects before they're fully attached to their reflector. I had to make a custom mechanism to dispatch the trace call - couldn't figure out how to get trait objects working for this case.
>
> This has been tested with the following zeal settings:
>
> GC after every allocation
> JS_GC_ZEAL=2,1
>
> GC after every 100 allocations (important for catching use-after-free bugs)
> JS_GC_ZEAL=2,100
>
> Verify pre barriers
> JS_GC_ZEAL=4,1
>
> Verify post barriers
> JS_GC_ZEAL=11,1
Source-Repo: https://github.com/servo/servo
Source-Revision: e7808c526c348fea5e3b48af70b7f1a066652097
This speeds up `./mach build --dev` followed by `./mach build-cef` by
25%. When rust-lang/cargo#497 is fixed, this speedup will increase
dramatically.
Source-Repo: https://github.com/servo/servo
Source-Revision: d6263c9b6e969fde4c644034e684a39d68667ad9
#6315
Set 'mach test-ref' default render mode to cpu and added a cli argument to 'mach test' to be able to select the render-mode, also renamed the 'kind' argument from 'test-ref' to '--render-mode' for coherence with reftest.rs
Source-Repo: https://github.com/servo/servo
Source-Revision: bedfa74b1f66a87dac00c46ac6560fa012f033d9
* Don't hang silently when passed a non-existant file.
* Fix uncaught exception in `mach run` when Servo fails.
Source-Repo: https://github.com/servo/servo
Source-Revision: 9b5a01e0455dde921b57d8e802e4554418477d8f
Fixes#6236
Also included in this commit are the changes need to make flake8 pass
for the existing python file
Source-Repo: https://github.com/servo/servo
Source-Revision: ccfe29d8f284dedc0101045d574a98fb1f69aa62
After #6268 merged, I found out that everything in the tree currently
passes the tidy checker.
---------------
It is worth pointing out that I personally do not know if this is a feature wanted by others. Once I noticed everything was already tidy, I decided to open this PR to start the conversation (if any). I am not convinced this is really a Good Thing, so my feelings would not get hurt if this was closed immediately.
Source-Repo: https://github.com/servo/servo
Source-Revision: 055182dae1d895ba2422e3da85c20a9a64beea71
The existing code for setting up the environment assumes that
the directory layout containing rust and cargo conforms to the
one used by rust-installer's tarballs. This makes overriding
the system root awkward for simple cases where I want to test
my own build directly from the rust build directory. This
patch just adds a second path to PATH and LD_LIBRARY_PATH
to accomodate both disk layouts.
Conflicts:
python/servo/command_base.py
Source-Repo: https://github.com/servo/servo
Source-Revision: 2e93ae7f76f9ceb6733352cfd0e16ab478f1d0a3
Trailing whitespace was found using flake8
This is working towards making flake8 part of the tidy process: #6236
Source-Repo: https://github.com/servo/servo
Source-Revision: 93f09b88c4f316804d13deaadac8ee91afedfb3b
Versions of git before 1.8.1 do not support git submodule --recursive sync
This commit makes update_submodules() exit with an error message if the version is <1.8.1
https://github.com/servo/servo/issues/5637
--------------------
This was originally written by @ringmaster101. The commit was cherry-picked by @frewsxcv and modified to address the comments brought up in #5648
Source-Repo: https://github.com/servo/servo
Source-Revision: 2fb8d31b0619a749256dfcd7c241f4b96e1a6d46
Fixes issue #6112
update-cargo and cargo-update both require that the user specifies the "-p" flag along with a specified package OR specify the "-a" flag to update all packages.
Let me know if this is not the right functionality.
Source-Repo: https://github.com/servo/servo
Source-Revision: c981e9b2e36d4428cd3d55c7f2073f398251e777
(And the same for `rr-record`.) For consistency with `mach build`.
Source-Repo: https://github.com/servo/servo
Source-Revision: 24635a4bcaec2e0033e1c178bf6f6bd3bead8942
Require either `--dev` or `--release`, unless a default build.mode is set in `.servobuild`. This is @jinankjain's patch from #5965, rebased onto master. It is already reviewed, and only waiting for servo/saltfs#28 to be deployed.
Source-Repo: https://github.com/servo/servo
Source-Revision: c0d8488b719ea72e73e435618e015c2f705853cc
Also refactors the notification function to introduce some single
responsibility.
Source-Repo: https://github.com/servo/servo
Source-Revision: 100e2b46916c3a35664e58f908042bcf9b87a83f
This is part of #5965. It needs to land before the rest of that PR, so we can land servo/saltfs#28 without breaking automated builds for other PRs. r? @larsbergstrom
Source-Repo: https://github.com/servo/servo
Source-Revision: 3e69bf8cd23caa5b691e42141d1111070ff831f5
Simplified the checking logic a bit too; only a single match per line and a stricter regex that matches everything in one go.
I tested this against commit 8b08c6f4 and made sure it caught the same problems. Note that tidy doesn't currently check the webidls, so those would have still made it through.
Source-Repo: https://github.com/servo/servo
Source-Revision: 387836c42e2377fc53d51d3404e6b91d170727a8
The 300 second threshold was originally from the Gecko/Firefox build system. It doesn't fit Servo builds, which are shorter, and often hover right around the 300 second mark (making the notification unpredictable).
Source-Repo: https://github.com/servo/servo
Source-Revision: 07aa6306f58b5d575a65ebaf5c71f510423ed8ca
Required by the latest version of the openssl-sys build script. Fixes#5145.
r? @larsbergstrom or @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 5502b5147f1e539032e6739fe8aa96c495ca2fae
Closes#5707. (Includes a rebase of it.)
Fixes#5688.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: f795440ee3be976d9819b011d4add7ceee3ade1e
This PR does two things.
* Solve Issue #5730
* Refactor `tidy.py` to reduce code duplication.
Source-Repo: https://github.com/servo/servo
Source-Revision: d654eada6f583871bdceade6506631b6b39ebad0
Supported for Linux & Windows platforms.
If it fails to generate the desktop notification, it simply gives a soft warning on the terminal.
This PR is solving Issue #5582.
Source-Repo: https://github.com/servo/servo
Source-Revision: a13fa9c0c00fe99b5af19d873a9240dce522f16b
The urllib version used a `FancyURLOpener` which use urllib. But urllib does not not handle proxies with SSL well.
For example, when adding the proxies to urllib.FancyURLOpener, I got this SSL error:
IOError: [Errno socket error] [Errno 1] _ssl.c:510: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
So I switched the function to urllib2.
A better solution would be to use `requests` but I prefer to stay with the "no-dependency" approach.
For example, this was my first solution with `requests`:
```python
def download(desc, src, dst):
print("Downloading(R) %s..." % desc)
with open(dst, 'wb') as handle:
response = requests.get(src, stream=True)
if not response.ok:
print("something went wrong downloading %s, :(" % desc)
sys.exit(1)
size = int(response.headers['content-length'])
block_size = 1024
recved = 0
for block in response.iter_content(1024):
recved += len(block)
pct = recved * 100.0 / size
print("\rDownloading %s: %5.1f%%" % (desc, pct), end="")
if not block:
break
handle.write(block)
print()
```
Source-Repo: https://github.com/servo/servo
Source-Revision: 43d476eb2babedac2ab5ab336fbfd6bae9372f16
On my laptop, running `./mach test-unit` goes from about 11 minutes to 22 seconds, when run after `./mach build`.
Fix#5291.
Source-Repo: https://github.com/servo/servo
Source-Revision: 017d1053617f6769d7f355e4a97d52ae67e53d1c
Moved from #5512. r? @larsbergstrom or @metajack or @Manishearth
Source-Repo: https://github.com/servo/servo
Source-Revision: bd7e4d661a6402a2b7821aa71aee977206b69925
