Not yet ready for merge, but you can start reviewing.
Still need to fix linux and some make check code.
Source-Repo: https://github.com/servo/servo
Source-Revision: b2e7e67087370e30a310bb3673b074c97c19d548
--HG--
rename : servo/src/components/style/common_types.rs => servo/src/components/style/properties/common_types.rs
rename : servo/src/components/style/properties.rs.mako => servo/src/components/style/properties/mod.rs.mako
rename : servo/src/components/util/debug.rs => servo/src/components/util/debug_utils.rs
This will allow multiple unions to contain the same type.
Source-Repo: https://github.com/servo/servo
Source-Revision: d448e97c6ac7c73336056be875ca99e5d63d75c3
This commit also includes improvements to the 'use' order in some of the
touched files.
Source-Repo: https://github.com/servo/servo
Source-Revision: 362af39b83b5eea56523bed8cc6e67c383e70a3d
This moves all the handling of optional arguments into `CGArgumentConverter`, and leaves `instantiateJSToNativeConversionTemplate` to only deal with the declaration of stack variables.
Source-Repo: https://github.com/servo/servo
Source-Revision: 48b1938ca3770f52187176e320cfdd148045a142
The defaultVisibility field was cloned from the C++ implementation,
where it tracks the difference between struct and class visibility.
Since no similar concept exists in Rust, it should be removed.
Source-Repo: https://github.com/servo/servo
Source-Revision: 6d381959db18acc5c2f0c1891df8afe5df8372cb
The long-term plan for SpiderMonkey is to eliminate JSContexts by merging
(most of) it into JSRuntime, so to future-proof our code, we should avoid
creating multiple JSContexts for the same JSRuntime.
However, this implies we'll have to use the same JSContext for objects in
different compartments, so we need to enter compartments. This is done by
using the with_compartment function.
Source-Repo: https://github.com/servo/servo
Source-Revision: d66197ae406e252c51bda48611ddfce78ecedb02
Is it reasonable to always expect success here for now?
Fixes#2246.
Source-Repo: https://github.com/servo/servo
Source-Revision: 310d2a19bbc1b8933f05cbd77c79df155ac00d94
As described in #1764, this strategy uses the following properties:
* DOM members are `JS<T>` types. These cannot be used with being explicitly rooted, but they are required for compiler-derived trace hooks.
* Methods that take DOM type arguments receive `&[mut] JSRef<T>`. These are rooted value references that are cloneable but cannot escape.
* Methods that return DOM values use `Unrooted<T>`. These are values that may or may not be rooted elsewhere, but callers must root them in order to interact with them in any way. One unsoundness hole exists - `Unrooted` values must be rooted ASAP, or there exists the danger that JSAPI calls could be made that could cause the underlying JS value to be GCed.
* All methods are implemented on `JSRef<T>`, enforcing the requirement that all DOM values are rooted for the duration of a method call (with a few exceptions for layout-related code, which cannot root values and therefore interacts with `JS<T>` and `&T` values - this is safe under the assumption that layout code interacts with DOM nodes that are in the tree, therefore rooted, and does not run concurrently with content code)
Source-Repo: https://github.com/servo/servo
Source-Revision: 731e66ff132e41cdc49bc5324c0e15be19c46ec2
It seems unlikely that this will ever be hit, but potentially hard to
figure out if it ever is hit.
Source-Repo: https://github.com/servo/servo
Source-Revision: 812d70942f74c793afabb8ff4fc120e92d586aaf
This just gets a working interface with dummy methods in place that can be built on. I'll implement stuff as we go along.
Blocks #2282
Source-Repo: https://github.com/servo/servo
Source-Revision: 53777807f96e64c64f1ef995f54e630122856366
- Fix#2128
- Take over from #2220
I didn't change `InterfaceTypes.rs` to `type.rs` because `type` is very common name which might be troublesome.
Source-Repo: https://github.com/servo/servo
Source-Revision: b36b779d24c6f7425f630c18495dae4c6edec137
This moves all handling of `isOptional` (except `type.isCallback()`, which I believe @jdm is rewriting in #2204) into one place.
Source-Repo: https://github.com/servo/servo
Source-Revision: 32bceb3ae7c1549739f94e3dce60a6de7ce770a9
r? @metajack
Note that all pending submodule PRs must be landed before this should be given r+.
Source-Repo: https://github.com/servo/servo
Source-Revision: 493aa2cdf30fb2ff5886c714030a20d714764b67
A js::rust::Compartment is little more than a glorified pointer to the
reflector of a window, so there's no good reason to use it. Instead, this
commit passes a JS<Window> directly when it's necessary.
This also means that we now have to use JS_DefineFunctions rather than
Compartment::define_functions; I believe the former is clearer to the reader
than the extra indirection involved in the latter calling through three
reopsitories.
This commit also simplifies ScriptTask::load to reuse the 'cx' local that is
in scope already, rather than refetching it through js_info.
Source-Repo: https://github.com/servo/servo
Source-Revision: 77b5c1f4f63c59ee88ad26363420fef6e2468ce1
...the dictionary conversion codegen.
This also explicitly disallows dictionary members without a default value, as
the code for those doesn't currently compile.
This is the second step of my planned rewrite of the dictionary initialization
that will remove the default values we currently use to initialize the
dictionary struct in the 'new' function.
Source-Repo: https://github.com/servo/servo
Source-Revision: 28d481664c3b45a20f0825c3fb6c79c9eba7140f
