I'm not sure if I like how I mostly just duplicated the code in CodegenRust.py, so that might need to be refactored.
Instead of just calling it Image, we might want to call it ConstructorImage, to make it clear that it's a constructor. Anyone have an opinion on that?
There seems to be a bug in the HTMLImageElement getter/setter as the value is 0 regardless of what I do. This seems to be unrelated to my commits, so I'll investigate that separately.
Source-Repo: https://github.com/servo/servo
Source-Revision: 57cc84b2935c429c92774649275625a7fd63973c
> 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 is necessary to ensure Cargo knows when to rebuild. Normally
.gitignore would be enough to exclude these from Cargo's freshness
calculation, but https://github.com/rust-lang/cargo/issues/1729 prevents
this currently. This is the new, correct way to do these thigns, just
like the style crate does.
Source-Repo: https://github.com/servo/servo
Source-Revision: ff59e1b8de67f1988522d6b6e6c4adda957fad5b
The cause of the issue is that the index of the overload to be invoked was being derived from the wrong lists (that contain only a subset of the overloads) - `possibleOverloads` and `interfaceSigs` rather than the `method.signatures()` (which contains all possible overloads).
Source-Repo: https://github.com/servo/servo
Source-Revision: b46ab0c60d53461d639c74d9c6b39d0c6c2d78c9
This should allow the jQuery testsuite to complete.
Source-Repo: https://github.com/servo/servo
Source-Revision: 9edc296c46b05606c74920a42ba0effb5c953db0
r? @jdm
I couldn't add the `getContextAttributes` method since `CodegenRust`
doesn't know how to return a dictionary value, I'll take a look at it ASAP.
I think the helper functions can return directly the renderer, since they're used just for that, but I wanted to hear your opinions about this.
By the way I'm interested in adding more serious tests for WebGL, and I think the [khronos conformance suit](https://github.com/KhronosGroup/WebGL/tree/master/conformance-suites/1.0.3) should be the best option.
Should I try to integrate it in wpt, or making a `tests/webgl` directory (or similar) inside the servo tree? (Maybe this question should be for @Ms2ger)
Source-Repo: https://github.com/servo/servo
Source-Revision: 0de09b936e5e37c15b7865157a98ad78b1077659
Fixes#3257
In eventtarget.rs I'm not sure whether ARG_NAMES actually needs to be static!?
Source-Repo: https://github.com/servo/servo
Source-Revision: 999325460ecc71b02160e8c79e71a694987d9acd
The proxy stringifiers called through {}.toString.call() (obj_toString) shouldn't use the stringifier.
Source-Repo: https://github.com/servo/servo
Source-Revision: 2c177794408bfbb5f8d6042f38639a5cba5eb2e5
fixes#5724, #5737
uses https://github.com/Manishearth/rust-tenacious (can be moved in-tree if needed)
I can make it `Deny` by default too (I'll add a cargo feature to tenacious), though we might want it on
`Warn` until we get some mileage on it.
Source-Repo: https://github.com/servo/servo
Source-Revision: d7987e43c944eb9b156bf3244c08fce4cb570db4
This addresses https://github.com/servo/servo/issues/3149. The immediate purpose is to support the constants in NodeFilter. The changes mostly follow the current Gecko Codegen.py. The main gist is that the generation of certain code artifacts is now gated by hasInterfaceObject() or hasInterfacePrototypeObject(), rather than by isCallback().
Source-Repo: https://github.com/servo/servo
Source-Revision: 1f9c2f9b34dede8182f45655b03380f8c26f3475
Fixes#1871
I thought I'd take a look at this for a first contribution to servo. A couple of things I'm not 100% sure on are:
1) `get_proto_or_iface_array` returns a `*mut *mut JSObj`, which I'm assuming is really an array of pointers to `JSObj`s. So dropping its return value will drop the memory for the array of pointers. Do we also need to drop each element, or is that handled by GC?
2) Are there any tests I need to add for this? I don't know if there are existing leak tests, or if leaks are mostly discovered by profiling.
Source-Repo: https://github.com/servo/servo
Source-Revision: 8998edb912b4f6efea7b2ff4e707325d7c03488c
Fix for issue #2108. That issue mentions an `unwrap_object` which doesn't seem to exist so I renamed `unwrap` to `native_from_reflector` and `unwrap_jsmanaged` to `native_from_reflector_jsmanaged`. The latter is a bit unweildy - maybe a shorter name might be better?
Source-Repo: https://github.com/servo/servo
Source-Revision: d7e9b8b96b77377fa37fd59cdb8c44fa866b5b2e
Previously, we had 'value' and 'this' locals, both storing a pointer to the
DOM object, for no good reason.
Source-Repo: https://github.com/servo/servo
Source-Revision: 92620c0a5f3bf01ddfb2f52fb89cdc467ff4a761
