The existing `Rooted` and `RootedVec` users were migrated the the following two macros:
```rust
let x = Rooted::new(cx, value);
// Was changed to:
rooted!(in(cx) let x = value);
// Which expands to:
let mut __root = Rooted::new_unrooted(value);
let x = RootedGuard::new(cx, &mut __root);
```
```rust
let mut v = RootedVec::new();
v.extend(iterator);
// Was changed to:
rooted_vec!(let v <- iterator);
// Which expands to:
let mut __root = RootableVec::new();
let v = RootedVec::new(&mut __root, iterator);
```
The `rooted!` macro depends on servo/rust-mozjs#272.
These APIs based on two types, a container to be rooted and a rooting guard, allow implementing both `Rooted`-style rooting and `Traceable`-based rooting in stable Rust, without abusing `return_address`.
Such macros may have been tried before, but in 1.9 their hygiene is broken, they work only since 1.10.
Sadly, `Rooted` is a FFI type and completely exposed, so I cannot prevent anyone from creating their own, although all fields but the value get overwritten by `RootedGuard::new` anyway.
`RootableVec` OTOH is *guaranteed* to be empty when not rooted, which makes it harmless AFAICT.
By fixing rust-lang/rust#34227, this PR enables Servo to build with `-Zorbit`.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fixrust-lang/rust#34227
- [x] These changes do not require tests because they are not functional changes
Source-Repo: https://github.com/servo/servo
Source-Revision: 80cb0cf8214fd52d2884724614c40cb278ee7575
We need the last inclusive ancestor of start node that is not an inclusive ancestor
of end node, not the first that is an inclusive ancestor of it.
Source-Repo: https://github.com/servo/servo
Source-Revision: dfdeabf57df02cf4b8a878b3b9933a08d156082d
The method needs to throw when trying to insert start node into range.
Source-Repo: https://github.com/servo/servo
Source-Revision: b3964a89585539082982160f5f4fb4bd05ddac2f
This makes all the `Range.deleteContents` tests pass.
I changed some `try!()`s for `unwraps()` because those calls are actually infallible.
r? @nox
Source-Repo: https://github.com/servo/servo
Source-Revision: 492e3241715e125df3587c8454ce52c925377152
Does the same thing as #6817, but storing Range instances directly in their start and end containers.
Cc @dzbarsky
Source-Repo: https://github.com/servo/servo
Source-Revision: 89ab368258eb827b0dcc8d6e6deecd3ed3c1de71
Sadly calling ExtractContents and discarding the result doesn't do the right thing.
It may be worth having a CutContents method that takes an `Option<DocumentFragment>` and switch the behavior based on it, to share the code between DeleteContents and ExtractContents, like what Gecko does. Maybe a followup.
Source-Repo: https://github.com/servo/servo
Source-Revision: e7b19249489eff7a7fd49bf458ee7bd681f8ad13
I initially used this to correctly handle ranges when their respective containers
are mutated, to get weak references of Range objects. I now realise that the weak
references should be handled at a lower level, closer to the JS-managed object.
Source-Repo: https://github.com/servo/servo
Source-Revision: e3bcf7bab7d0340fc7ebd0e58a2cde34e534c1cf
Removes all those messy FooCast structures in InheritTypes.rs.
Source-Repo: https://github.com/servo/servo
Source-Revision: 674589c370d978f543e71f995d58c5b28e6e9842
We can only borrow `JS<T>` from rooted things, so it's safe to deref it.
The only types that provide mutable `JS<T>` things are `MutHeap<JS<T>>` and
`MutNullableHeap<JS<T>>`, which don't actually expose that they contain
`JS<T>` values.
Source-Repo: https://github.com/servo/servo
Source-Revision: 1a376aa75d5de8781b17a673850860f8afd2c28f
This frees us forever from caring about maintaining these enums. The last commit removes their use from the initialisation of interface objects derived from Node.
Source-Repo: https://github.com/servo/servo
Source-Revision: 32daa17d5cbcad02db0713e21e52410cdc60480e
Now that `JSRef<T>` is gone, there is no need to have helper traits.
Source-Repo: https://github.com/servo/servo
Source-Revision: 909429702972d53bf02dfe9a4aa93ea0cb588cf4
The integration is off by default for now. You can try it out with `./mach build --features "script/plugins/clippy"`.
We're using a branch of clippy with some of the lints changed to Allow, either because they don't apply to us, or because they're noisy and dwarf other warnings (but still should be fixed)
After going through the rest of Servo's warnings I'll figure out which lints we should be keeping.
There's a cargo bug with optional deps that makes it hard for this to work with Cargo.lock -- so this PR contains no changes to lockfiles (and running the build with clippy on may dirty the lockfile, though it gets fixed later)
Source-Repo: https://github.com/servo/servo
Source-Revision: 50e1c967e4299c1515575f73d407f5f6b977d818
Expands on the work by @wilmoz and cleans up the existing errors. Closes#7180. Closes#7111.
Source-Repo: https://github.com/servo/servo
Source-Revision: e74825f9fde8e222f4ba9bb24b2c2a3864c73e5f
Also adds HeapSizeOf implementations/derive for some types. I've used "Cannot calculate Heap size" as a reason everywhere, because my imagination is rather limited. If you'd like me to change this message for specific types, please write something like this: "Trusted - Cannot calculate Heap size for Trusted" so that it would be easier for me to replace them through a script :)
Source-Repo: https://github.com/servo/servo
Source-Revision: a03616f379c255cc6c9b6e1d04dd7d98bd9926ce
Gecko doesn't really follow the spec but it seems to throw a HierarchyRequest error when parent is null.
Any ideas who I should talk to about fixing the spec to account for the null checks?
Source-Repo: https://github.com/servo/servo
Source-Revision: acf47a02cf38b5c82e7c78cc1f6660a7daa9969a
fixes#6524. I had to make an additional change not mentioned in the ticket - adding the `#[feature]` to enable deriving custom traits but I assume that's expected at this time.
Source-Repo: https://github.com/servo/servo
Source-Revision: bbb39082e0f640400546d2084a450a8675820a82
> 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
The actual boundary points are behind a Rc<_> value to let nodes be able to store weak references to them in the future.
Source-Repo: https://github.com/servo/servo
Source-Revision: 15c4372a8be9c2b73d9e09bd7684484e48d220e8
Extracted this out of #5649
This commit was created with the following commands:
```
find . -iname "*.webidl" -type f -print0 | xargs -0 sed -i '' 's/http:\(.*\)whatwg.org/https:\1whatwg.org/g'
```
```
find . -iname "*.rs" -type f -print0 | xargs -0 sed -i '' 's/http:\(.*\)whatwg.org/https:\1whatwg.org/g'
```
Source-Repo: https://github.com/servo/servo
Source-Revision: 4997d3a112354a407365fede1ab1944834a2e13c
This is a start towards fixing #3868. Not all callers have been fixed yet, so the `Deref` implementation remains for now.
Source-Repo: https://github.com/servo/servo
Source-Revision: 141b5d038fad3c0c44a6f1b309b8ca9edea54580
Now `#[dom_struct]` also generates Reflectable impls, and there's another lint to ensure that a DOM struct only contains one bare DOM field (as the first field) or a Reflector.
A lot of this was generated by sed -- each autogenerated change has its own commit for easy review; these will be squashed later.
Source-Repo: https://github.com/servo/servo
Source-Revision: 56d1b16d1b3a18d5ffa1d9c32562d3b209851711
This PR removes public fields from all (hope I didn't miss any) DOM structs. Should |Page| be privatized as well? This PR additionally introduces a #[privatize] lint to ensure nobody accidentally re-introduces a public field.
All changesets compile separately if applied in the same order. Hope that helps reviewing but I can of course squash them before merging.
Source-Repo: https://github.com/servo/servo
Source-Revision: f350879574194bb612eac88e21d0920e9827afa7
