Changed write functions of FileSystemSyncAccessHandle to accept immutable buffers

[kipcode66]

Removed unnecessary mut for the write functions.

According to the MDN documentation, there should not be any modification applied to the buffer, so this should be completely fine.

Should resolve #3536

[snOm3ad]

You might want to look at this section of the wasm-bindgen guide. These files are generated by the crate webidl so it's not possible to modify them manually, you need to regenerate them.

The part that is of interest is here:

wasm-bindgen/crates/webidl/src/util.rs

Lines 511 to 534 in b76af3b

	/// When generating our web_sys APIs we default to setting slice references that
	/// get passed to JS as mutable in case they get mutated in JS.
	///
	/// In certain cases we know for sure that the slice will not get mutated - for
	/// example when working with the WebGlRenderingContext APIs.
	///
	/// Here we implement a whitelist for those cases. This whitelist is currently
	/// maintained by hand.
	///
	/// When adding to this whitelist add tests to crates/web-sys/tests/wasm/whitelisted_immutable_slices.rs
	fn maybe_adjust<'a>(&self, mut idl_type: IdlType<'a>, id: &'a OperationId) -> IdlType<'a> {
	let op = match id {
	OperationId::Operation(Some(op)) => op,
	OperationId::Constructor(Some(op)) => op,
	_ => return idl_type,
	};
	if IMMUTABLE_SLICE_WHITELIST.contains(op) {
	flag_slices_immutable(&mut idl_type)
	}
	idl_type
	}
	}

By default slice references that get passed to JS are mutable. In order to make them immutable you need to whitelist them and then regenerate the API.

[snOm3ad]

LGTM! I'm not in the contributors list so I can't merge your PR, but maybe @daxpedda can.

[kipcode66]

I noted that when I added this fix, it also modified the methods for IDBFileHandle, but when I go to MDN, the documentation for that class doesn't seem to exist anymore. Since it's not even available anyway, I don' think this should be an issue.

My belief is that it should probably be removed if it's not even listed in MDN.

[ranile]

This is a breaking change (playground)

[kipcode66]

It might be a breaking change, but it's in the unstable API (which from what I can understand, when an API is unstable, we should expect breaking changes if necessary).

In my specific use case, I am working with files that have sizes larger than I can load directly on the available RAM in a browser. In order to work on those files, I'm directly loading and saving into files after processing them in chunks. However, the chunks can still be quite large, and I already encountered files which would require chunks that, if I needed to allocate an intermediary buffer each time to change the mutability, would overflow the available memory.

I believe I could import a function that would use the right signature myself, but the cleaner solution would be to fix the API.

[snOm3ad]

This is a breaking change (playground)

This isn't the case though, from client side the reference is already required to be mut. There's no code out there that uses this API with an immutable reference.

fn original(b: &mut [u8]);
fn proposed(b: &[u8]);

Calling proposed like proposed(&mut [1, 2, 3]) does not produce an error (playground). What @kipcode66 is doing is moving the API from a stricter version into a less strict version.

[daxpedda]

Apologies for my absence.

I believe this is technically still a breaking change because it can mess up inference, but I consider this a very minor breaking change.
It is also true that this is an experimental API where a breaking change is not an issue, but unfortunately the whitelisting also affected IdbFileHandle.write, which isn't an experimental API, which is funny because this API is deprecated anyway.

All in all I'm happy to merge this.
Small nit: please add an entry to the changelog.

@hamza1311 I would appreciate your approval as well.

[daxpedda]

Thank you!

[ranile]

I had missed that it's part of unstable API as part of my previous review, sorry about that. This looks good to me.