`shell.nix`: Add `libxkbcommon` to `LD_LIBRARY_PATH`
`libxkbcommon` is a runtime dependency of winit's Wayland backend. Servo crashes with [a very confusing panic message][1] if the Wayland backend is selected, and `libxkbcommon.so` can't be found at runtime.
[1]: https://github.com/rust-windowing/winit/issues/1760
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
---
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they don't affect the production code
docs: Fix link to experimental CLI prefs list
Fixes: #28612.
Signed-off-by: Divyanshu Agrawal <agrawal-d@outlook.com>
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#28612 (GitHub issue number if applicable)
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because these are documentation changes.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
CI: Update the required clang-format version to 13
`mach test-tidy` requires a specific version of `clang-format` so that the formatting result is consistent between build environments. [The virtual environment][6] used by GitHub Actions has been updated [**again**][1] and now provides a version of `clang-format` that is different from the one expected by our `mach` tool, causing the `mach test-tidy --force-cpp` step to [fail][2]. This PR updates our tool to address the issue.
[6]: https://github.com/actions/virtual-environments
[1]: https://github.com/servo/servo/pull/28602
[2]: https://github.com/servo/servo/pull/28613#issuecomment-944424519
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
---
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they don't change the production code
Delete `canvas.png`
This PR deletes `:/canvas.png`, which was presumably accidentally added by commit 5f91ab07.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
---
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because this file is used absolutely nowhere
Update rust by example link
<!-- Please describe your changes on the following line: -->
rustbyexample.com shows 404
---
- [x] These changes do not require tests because this just updates a text file
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Fix CI
This PR fixes CI failures that have occurred due to external reasons.
# Highlights
## `blessing`
Our `mach` script uses [`blessings`][2] for terminal rendering during WPT tests. The `setuptools` script of `blessings` 1.6 activates the option `use_2to3` to convert the code when installing the package for Python 3. However, this option has been [removed][1] in `setuptools` 58. This caused a breakage in our CI pipelines, producing an error message like the following:
```
Collecting blessings==1.6
Downloading blessings-1.6.tar.gz (19 kB)
ERROR: Command errored out with exit status 1:
command: /home/runner/work/servo/servo/python/_virtualenv3.8/bin/python -c 'import io, os, sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-n51ah1i5/blessings_f1c0f646d72e488e988232f7aeb42946/setup.py'"'"'; __file__='"'"'/tmp/pip-install-n51ah1i5/blessings_f1c0f646d72e488e988232f7aeb42946/setup.py'"'"';f = getattr(tokenize, '"'"'open'"'"', open)(__file__) if os.path.exists(__file__) else io.StringIO('"'"'from setuptools import setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info --egg-base /tmp/pip-pip-egg-info-1eg28bh4
cwd: /tmp/pip-install-n51ah1i5/blessings_f1c0f646d72e488e988232f7aeb42946/
Complete output (1 lines):
error in blessings setup command: use_2to3 is invalid.
----------------------------------------
WARNING: Discarding https://files.pythonhosted.org/packages/af/4a/61acd1c6c29662d3fcbcaee5ba95c20b1d315c5a33534732b6d81e0dc8e8/blessings-1.6.tar.gz#sha256=edc5713061f10966048bf6b40d9a514b381e0ba849c64e034c4ef6c1847d3007 (from https://pypi.org/simple/blessings/). Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.
ERROR: Could not find a version that satisfies the requirement blessings==1.6 (from versions: 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.5.1, 1.6, 1.6.1, 1.7)
ERROR: No matching distribution found for blessings==1.6
"/home/runner/work/servo/servo/python/_virtualenv3.8/bin/python" "-m" "pip" "install" "-I" "-r" "/home/runner/work/servo/servo/python/requirements.txt" failed with error code 1:
Output:
Error:
Error: Process completed with exit code 1.
```
Our `requirements.txt` pins the version of `setuptools`, but this didn't work probably because `virtualenv` uses an embedded version of `setuptools`, which was recently [upgraded][4] to 58 in `virtualenv` 20.8.0.
This PR upgrades `blessings` to a version that [doesn't use][3] the `use_2to3` option anymore to fix this issue.
## OpenSSL Binding
It appears that, when installing OpenSSL, Homebrew now installs version 3.0 by default. OpenSSL 3.0 isn't supported by `openssl-sys` 0.9.63 that we currently use and causes a build error while building the binding.
```
build/expando.c:10:1: error: pasting formed 'RUST_VERSION_OPENSSL_(', an invalid preprocessing token
VERSION(OPENSSL, OPENSSL_VERSION_NUMBER)
^
build/expando.c:5:23: note: expanded from macro 'VERSION'
#define VERSION(n, v) VERSION2(n, v)
^
build/expando.c:4:43: note: expanded from macro 'VERSION2'
#define VERSION2(n, v) RUST_VERSION_##n##_##v
^
1 error generated.
```
This PR upgrades `openssl[-sys]` to newer versions that were [updated][5] to support OpenSSL 3.0.
## `clang-format`
`mach test-tidy` requires a specific version of `clang-format` so that the formatting result is consistent between build environments. [The virtual environment][6] used by GitHub Actions has been [updated][7] and now provides a version of `clang-format` that is different from the one expected by our `mach` tool. This PR updates our tool to address the issue.
[1]: https://github.com/pypa/setuptools/blob/main/CHANGES.rst#v5800
[2]: https://github.com/erikrose/blessings
[3]: https://github.com/erikrose/blessings/pull/132
[4]: https://github.com/pypa/virtualenv/blob/main/docs/changelog.rst#v2080-2021-09-16
[5]: b4c735e8af
[6]: https://github.com/actions/virtual-environments
[7]: https://github.com/actions/virtual-environments/pull/3905/files#diff-816219d3c9f30fcc1c40f88ca826c1662bf99eded781c1b419dd2dfb577ae227R380
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
---
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they don't change the production code
Fix simpleservo binary check on macos
<!-- Please describe your changes on the following line: -->
When compiling libsimpleservo on MacOS 11.5.2 I would get an error at the end of the process saying
```
Error running mach:
['build', '-d', '--libsimpleservo']
The error occurred in code that was called by the mach command. This is either
a bug in the called code itself or in the way that mach is calling it.
You can invoke |./mach busted| to check if this issue is already on file. If it
isn't, please use |./mach busted file| to report it. If |./mach busted| is
misbehaving, you can also inspect the dependencies of bug 1543241.
If filing a bug, please include the full output of mach, including this error
message.
The details of the failure are as follows:
servo.command_base.BuildNotFound: No Servo binary found. Perhaps you forgot to run `./mach build`?
File "/Users/yuriwitte/_HtmlTests/servo/python/servo/build_commands.py", line 734, in build
self.get_binary_path(release, dev, target=target, simpleservo=libsimpleservo)
File "/Users/yuriwitte/_HtmlTests/servo/python/servo/command_base.py", line 394, in get_binary_path
raise BuildNotFound('No Servo binary found.'
```
The binary is there, it's just that `get_binary_path` on `command_base.py` checks for a libsimpleservo **.so** instead of a **.dylib**. This pr fixes this check.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [ ] These changes fix: didn't find a specific issue for this, but these two are also related to file extensions on MacOS:
https://github.com/servo/servo/issues/27654https://github.com/servo/servo/issues/27318
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because: they _are_ the tests I guess?
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Update docs for VS2019 and clarify
This mostly updates Windows docs, clarifies and removes some unnecessary parts.
The long chocolatey command gives more insight into what it's doing, it still gives us the same components as before (but 2019), without VS itself.
I also used `./mach clean` a few times and had one problem due to `python/_virtualenv[version]/` not being removed completely, so I clarified what the `clean`-command does (I thought it just passes on to cargo).
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#28530 (and maybe #25845)
- [X] These changes do not require tests because it's just docs
The condition for exposing a cross-origin setter should be `CrossOriginWritable`, not `CrossOriginReadable`
Fixes `Location#href` being inaccessible from a cross-origin document.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
---
- [x] There are tests for these changes OR
- [ ] These changes do not require tests because ___
The expression `crossOriginIframe.contentWindow.location.href = "new
href"` takes the following steps: (1) Get the setter for `href` by
invoking `[[GetOwnProperty]]` on `crossOriginIframe.contentWindow.
location`. (2) Call the setter, passing `crossOriginIframe.
contentWindow` and `"new href"`. Since the target `Location` is cross
origin, getting the setter succeeds only if the `CrossOriginWritable`
extended attribute is present on the `href` attribute, and it's present.
However, instead of `CrossOriginWritable`, `CrossOriginReadable` was
checked mistakenly.
Since `Location#href` has `CrossOriginWritable` but not
`CrossOriginReadable`, this bug rendered `Location#href` inaccessible
from a cross-origin document.
Fix compiler warnings
<!-- Please describe your changes on the following line: -->
While working on my other pull request, I noticed that there were a few compiler warnings that are easy to fix since they simply note some deprecated syntax that can be fixed with no semantic difference. I decided to quickly fix them and submit a PR.
There was also one place where an allowance of unsafe code was not being applied to the correct thing in `components/script/dom/cssrulelist.rs`. It was being applied to a macro `unsafe_no_jsmanaged_fields!` which does contain unsafe code. My understanding (and what the compiler warning states) is that applying that annotation to a macro does nothing even if the macro contains unsafe code. So what I have done is moved this annotation to apply to the entire file. I do not know if that is even necessary since the macro definition is in another file. It would be good to know since it would be best to not add extra allowances when they aren't needed. The compiler warning is below if that helps:
```
warning: unused attribute `allow`
--> components/script/dom/cssrulelist.rs:24:1
|
24 | #[allow(unsafe_code)]
| ^^^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(unused_attributes)]` on by default
note: the built-in attribute `allow` will be ignored, since it's applied to the macro invocation `unsafe_no_jsmanaged_fields`
--> components/script/dom/cssrulelist.rs:25:1
|
25 | unsafe_no_jsmanaged_fields!(RulesSource);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
```
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable) (No issue number)
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because they fix compiler warnings in a way that does not change semantics except as noted.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
CI: Don't cancel the entire job matrix when one of them fails
By default, GitHub Actions [cancels][1] all in-progress jobs in a build matrix when one of them fails. This PR disables this behavior.
[1]: https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstrategyfail-fast
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
---
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they are for CI
Update script_plugin for rust-lang/rust#85296
This will update the script_plugin for the plugin interface changes in rust-lang/rust#85296.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [ ] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because it is a fix for rustc changes.
