Bindings for TypedArray subclasses #486
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Rebased on master to fix merge conflicts and fix compatibility with latest Nightly Rust |
src/js.rs
Outdated
| /// | ||
| /// http://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/TypedArray/fill | ||
| #[wasm_bindgen(method)] | ||
| pub fn fill(this: &Float32Array, value: JsValue, start: u32, end: u32) -> Float32Array; |
There was a problem hiding this comment.
This was previously JsValue here but I wonder if this would be better bound as f32? (or the appropriate type on each array below)
There was a problem hiding this comment.
Seems sensible to me. Perhaps the JsValue was there only because that's the type on Array.fill()
alexcrichton
approved these changes
Jul 17, 2018
alexcrichton
added a commit
to alexcrichton/wasm-bindgen
that referenced
this pull request
Jul 17, 2018
Not a lot of attention has been paid to dealing with conflicts of symbols between crates and different `#[wasm_bindgen]` blocks. This commit starts to fix this issue by unblocking rustwasm#486 which first ran into this. Currently there's a bug where if two independent crates bind the same JS API they'll generate the same symbol which causes conflicts for things like LTO or linking in general. This commit starts to add a "salt" to all symbols generated by `wasm-bindgen` (these are all transparent to the user) to ensure that each crate's invocations are kept apart from one another and using the correct bindings.
|
rust-lang/rust#52474 is the accompanying Rust PR to fix the diagnostic here |
alexcrichton
added a commit
to alexcrichton/wasm-bindgen
that referenced
this pull request
Jul 17, 2018
Not a lot of attention has been paid to dealing with conflicts of symbols between crates and different `#[wasm_bindgen]` blocks. This commit starts to fix this issue by unblocking rustwasm#486 which first ran into this. Currently there's a bug where if two independent crates bind the same JS API they'll generate the same symbol which causes conflicts for things like LTO or linking in general. This commit starts to add a "salt" to all symbols generated by `wasm-bindgen` (these are all transparent to the user) to ensure that each crate's invocations are kept apart from one another and using the correct bindings.
alexcrichton
added a commit
that referenced
this pull request
Jul 17, 2018
Not a lot of attention has been paid to dealing with conflicts of symbols between crates and different `#[wasm_bindgen]` blocks. This commit starts to fix this issue by unblocking #486 which first ran into this. Currently there's a bug where if two independent crates bind the same JS API they'll generate the same symbol which causes conflicts for things like LTO or linking in general. This commit starts to add a "salt" to all symbols generated by `wasm-bindgen` (these are all transparent to the user) to ensure that each crate's invocations are kept apart from one another and using the correct bindings.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
More progress towards #275. This exposes the bindings for constructors and
fillmethods forUint16Array,Uint32Array,Uint8ClampedArray,Int8Array,Int16Array,Int32Array,Float32Array, andFloat64Array, following very closely the already-existing support forUint8Arraysupplied in #316. Small tweaks to the existingUint8Arraycode (moved to alphabetical position injs.rs, refactored tests) are included in this PR.Feedback welcome - this is my first contribution to this project, and actually to any project written in the Rust language.