The warning occurs when compiling the script bindings unit-tests `./mach
test-unit -p script_bindings --lib`.
Presumably in some contexts the inner macro is already imported, which
triggers the warning.
Directly using `crate::` avoids this.
The fixed warning:
```
warning: unused import: `$crate::match_domstring_ascii_inner`
--> components/script_bindings/domstring.rs:1050:17
|
1050 | use $crate::match_domstring_ascii_inner;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
1352 | let _res = match_domstring_ascii!(s,
| ____________________-
1353 | | "❤" => true,
1354 | | _ => false,);
| |________________________- in this macro invocation
|
= note: this warning originates in the macro `match_domstring_ascii` (in Nightly builds, run with -Z macro-backtrace for more info)
```
Testing: Manually tested the warning is fixed by running `./mach
test-unit -p script_bindings --lib`.
---------
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
This was the last failure in this directory. To fix it, I had to spelunk
into a couple of places:
1. We shouldn't use the `base_element()` of the document, but select the
first base element, regardless if it has an empty href or not
2. We didn't implement target checking for elements. Only some values
are valid and an empty target (which the test also confusingly uses) is
not valid. Hence, it should fallback to the base element
3. We weren't sanitizing the value in case it contains an ASCII tab or
newline + U+003C. This is true for both the form target as well as for
other link elements.
All in all, added a lot more specification text to figure out what was
going on.
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
This moves the Unicode offset types to the `base` crate and makes them
generally more usable throughout the Servo codebase. In addition, they
are renamed to use Rust naming and to be a bit more consistent:
- `UTF8Bytes` -> `Utf8CodeUnitLength`
- `UTF16CodeUnits` -> `Utf16CodeUnitLength`
There is also a bit more documentation explaining their use.
This is preparation for fixing issues with UTF-16 offsets in editable
text fields.
Testing: This does not change behavior so existing WPT tests should
suffice.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
This implements character set restrictions both for the DOM API and when
getting cookies from http/ws headers. This is a local workaround for
https://github.com/rwf2/cookie-rs/issues/243
We still fail some tests because hyper errors out when parsing headers
with %x1 characters.
This patch also makes a minor change to
'ServoCookie::from_cookie_string()' to avoid some string cloning when
possible.
Testing: wpt tests expectations are updated
Signed-off-by: webbeef <me@webbeef.org>
This implements efficient methods for as_bytes, eq_ascii, is_ascii and
to_jsval.
Tests were added for as_bytes. Additionally, BytesView now has an
internal type to make sure nobody can construct it.
Testing: New unit tests were added and some old ones covered the new
functions.
---------
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
Somewhere in the transition to SafeJSContext, I did not merge correctly
and used the DOMString::from_String method instead of the
DOMString::from_js_string method, hence, defeating the lazyness.
This fixes this.
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
Testing: Compiling and the function was enabled on a local branch
earlier.
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
This implements the following methods in a more efficient way using the
Latin1 representation:
- starts_with,
- to_ascii_lowercase,
- contains_html_space_characters,
- is_ascii_lowercase,
- PartialEq<str>, PartialEq<String>, PartialEq<DOMString>,
- Atom::from, LocalName::from, NameSpace::from
- Removed find which was not used.
All of these methods have new tests included.
---------
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
This replaces the implementation of is_empty and len with more efficient
representation without conversion
and allocation based on the underlying bytes.
For this we use a new view, EncodedBytesView.
Additionally, we implement a new macro `match_domstring_ascii!` which
allows simple match clauses
matching ascii strings with DOMStrings without conversion/allocation.
The macro will panic in debug builds if the strings are non-ascii but
will not match all DOMStrings correctly.
We replaced the usage of `DOMString::str()` in many places with this
macro.
Testing: len and is_empty were already covered by tests.
match_domstring_ascii! has more unit tests added with this PR.
---------
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
The current code has snippets like
`self.convert_string_to_number(&DOMString::from(attr.summarize().value))`
in various places.
The snippet wants to take the value of an attribute and parse it as a
number. In theory this is an easy problem, the attribute internally
stores a `AttrValue` (which can be treated as `str`) and the conversion
code wants a `str` - no conversions or copies necessary!
But the reality of what happens is less ideal:
`attr.summarize` allocates a `AttrInfo` containing owned copies of the
attributes namespace, name and value. The name and value are also
converted from the `AttrValue` to a `DOMString` and then back to a
`String` in the process. And then we take the value field from
`AttrInfo` and create a new DOMString from it, passing that to
`self.self.convert_string_to_number` - which ends up internally calling
`str()` on it.
All in all this is not a big issue, because this code doesn't run often.
But it's also not hard to fix, and we end up with cleaner code in the
process.
Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
This implements LazyDOMString (from now on DOMString) as outlined in
https://github.com/servo/servo/issues/39479.
Constructing from a *mut JSString we keep the in a
RootedTraceableBox<Heap<*mut JSString>> and transform
the string into a rust string if necessary via the `make_rust_string`
method.
Methods used in script are implemented on this string. Currently we
transform the string at all times.
But in the future more efficient implementations are possible.
We implement the safety critical sections in a separate module
DOMStringInner which allows simple constructors, `make_rust_string` and
the `bytes` method.
This method returns the new type `EncodedBytes` which contains the
reference to the underlying string in either format.
Testing: WPT tests still seem to work, so this should test this
functionality.
---------
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
