Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update to string-cache 0.3 #14043

Merged
merged 1 commit into from Nov 3, 2016
Merged

Update to string-cache 0.3 #14043

merged 1 commit into from Nov 3, 2016

Conversation

@SimonSapin
Copy link
Member

SimonSapin commented Nov 3, 2016

Previously, string-cache defined:

  • An string-like Atom type,
  • An atom!("foo") macro that expands to a value of that type, for a set of strings known at compile-time,
  • A struct Namespace(Atom); type
  • A ns!(html) macro that maps known prefixed to Namespace values with the corresponding namespace URL.

Adding a string to the static set required making a change to the string-cache crate.

With 0.3, the Atom type is now generic, with a type parameter that provides a set of static strings. We can have multiple such sets, defined in different crates. The string_cache_codegen crate, to be used in build scripts, generates code that defines such a set, a new atom type (a type alias for Atom<_> with the type parameter set), and an atom!-like macro.

The html5ever repository has a new html5ever_atoms crate that defines three such types: Prefix, Namespace, and LocalName (with respective namespace_prefix!, namespace_url!, and local_name! macros). It also defines the ns! macro like before.

This repository has a new servo_atoms crate in components/atoms that, for now, defines a single Atom type (and atom!) macro. (servo_atoms::Atom is defined as something like type Atom = string_cache::Atom<ServoStaticStringSet>;, so overall there’s now two types named Atom.)

In this PR, servo_atoms::Atom is used for everything else that was string_cache::Atom before. But more atom types can be defined as needed. Two reasons to do this are to auto-generate the set of static strings (I’m planning to do this for CSS property names, which is the motivation for this change), or to have the type system help us avoid mix up unrelated things (this is why we had a Namespace type ever before this change).

Introducing new types helped me find a bug: when creating a new attribute dom::Element::set_style_attr, would pass Some(atom!("style")) instead of None (now Option<html5ever_atoms::Prefix> instead of Option<string_cache::Atom>) to the prefix argument of Attr::new. I suppose the author of that code confused it with the local_name argument.


Note that Stylo is not affected by any of this. The gecko_string_cache module is unchanged, with a single Atom type. The style crate conditionally compiles Prefix and LocalName re-exports for that are both gecko_string_cache::Atom on stylo.


  • ./mach build -d does not report any errors
  • ./mach test-tidy does not report any errors
  • These changes fix #__ (github issue number if applicable).
  • There are tests for these changes OR
  • These changes do not require tests because _____

This change is Reviewable

@nox
Copy link
Member

nox commented Nov 3, 2016

@bors-servo
Copy link
Contributor

bors-servo commented Nov 3, 2016

📌 Commit b16f9da has been approved by nox

@SimonSapin
Copy link
Member Author

SimonSapin commented Nov 3, 2016

@bors-servo p=1000

This will bitrot so fast

@bors-servo
Copy link
Contributor

bors-servo commented Nov 3, 2016

Testing commit b16f9da with merge 4926dd3...

bors-servo added a commit that referenced this pull request Nov 3, 2016
Update to string-cache 0.3

Previously, `string-cache` defined:
*  An string-like `Atom` type,
* An `atom!("foo")` macro that expands to a value of that type, for a set of strings known at compile-time,
* A `struct Namespace(Atom);` type
* A `ns!(html)` macro that maps known prefixed to `Namespace` values with the corresponding namespace URL.

Adding a string to the static set required making a change to the `string-cache` crate.

With 0.3, the `Atom` type is now generic, with a type parameter that provides a set of static strings. We can have multiple such sets, defined in different crates. The `string_cache_codegen` crate, to be used in build scripts, generates code that defines such a set, a new atom type (a type alias for `Atom<_>` with the type parameter set), and an `atom!`-like macro.

The html5ever repository has a new `html5ever_atoms` crate that defines three such types: `Prefix`, `Namespace`, and `LocalName` (with respective `namespace_prefix!`, `namespace_url!`, and `local_name!` macros). It also defines the `ns!` macro like before.

This repository has a new `servo_atoms` crate in `components/atoms` that, for now, defines a single `Atom` type (and `atom!`) macro. (`servo_atoms::Atom` is defined as something like `type Atom = string_cache::Atom<ServoStaticStringSet>;`, so overall there’s now two types named `Atom`.)

In this PR, `servo_atoms::Atom` is used for everything else that was `string_cache::Atom` before. But more atom types can be defined as needed. Two reasons to do this are to auto-generate the set of static strings (I’m planning to do this for CSS property names, which is the motivation for this change), or to have the type system help us avoid mix up unrelated things (this is why we had a `Namespace` type ever before this change).

Introducing new types helped me find a bug: when creating a new attribute `dom::Element::set_style_attr`, would pass `Some(atom!("style"))` instead of `None` (now `Option<html5ever_atoms::Prefix>` instead of `Option<string_cache::Atom>`) to the `prefix` argument of `Attr::new`. I suppose the author of that code confused it with the `local_name` argument.

---

Note that Stylo is not affected by any of this. The `gecko_string_cache` module is unchanged, with a single `Atom` type. The `style` crate conditionally compiles `Prefix` and `LocalName` re-exports for that are both `gecko_string_cache::Atom` on stylo.

---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).

<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____

<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
@bors-servo
Copy link
Contributor

bors-servo commented Nov 3, 2016

💔 Test failed - mac-dev-unit

@SimonSapin SimonSapin force-pushed the string-cache-up branch from b16f9da to 53b638c Nov 3, 2016
@SimonSapin
Copy link
Member Author

SimonSapin commented Nov 3, 2016

@bors-servo r=nox

Updated CEF lockfile again post-rebase.

@bors-servo
Copy link
Contributor

bors-servo commented Nov 3, 2016

📌 Commit 53b638c has been approved by nox

@bors-servo
Copy link
Contributor

bors-servo commented Nov 3, 2016

Testing commit 53b638c with merge 4aeeed4...

bors-servo added a commit that referenced this pull request Nov 3, 2016
Update to string-cache 0.3

Previously, `string-cache` defined:
*  An string-like `Atom` type,
* An `atom!("foo")` macro that expands to a value of that type, for a set of strings known at compile-time,
* A `struct Namespace(Atom);` type
* A `ns!(html)` macro that maps known prefixed to `Namespace` values with the corresponding namespace URL.

Adding a string to the static set required making a change to the `string-cache` crate.

With 0.3, the `Atom` type is now generic, with a type parameter that provides a set of static strings. We can have multiple such sets, defined in different crates. The `string_cache_codegen` crate, to be used in build scripts, generates code that defines such a set, a new atom type (a type alias for `Atom<_>` with the type parameter set), and an `atom!`-like macro.

The html5ever repository has a new `html5ever_atoms` crate that defines three such types: `Prefix`, `Namespace`, and `LocalName` (with respective `namespace_prefix!`, `namespace_url!`, and `local_name!` macros). It also defines the `ns!` macro like before.

This repository has a new `servo_atoms` crate in `components/atoms` that, for now, defines a single `Atom` type (and `atom!`) macro. (`servo_atoms::Atom` is defined as something like `type Atom = string_cache::Atom<ServoStaticStringSet>;`, so overall there’s now two types named `Atom`.)

In this PR, `servo_atoms::Atom` is used for everything else that was `string_cache::Atom` before. But more atom types can be defined as needed. Two reasons to do this are to auto-generate the set of static strings (I’m planning to do this for CSS property names, which is the motivation for this change), or to have the type system help us avoid mix up unrelated things (this is why we had a `Namespace` type ever before this change).

Introducing new types helped me find a bug: when creating a new attribute `dom::Element::set_style_attr`, would pass `Some(atom!("style"))` instead of `None` (now `Option<html5ever_atoms::Prefix>` instead of `Option<string_cache::Atom>`) to the `prefix` argument of `Attr::new`. I suppose the author of that code confused it with the `local_name` argument.

---

Note that Stylo is not affected by any of this. The `gecko_string_cache` module is unchanged, with a single `Atom` type. The `style` crate conditionally compiles `Prefix` and `LocalName` re-exports for that are both `gecko_string_cache::Atom` on stylo.

---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).

<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____

<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/14043)
<!-- Reviewable:end -->
@bors-servo
Copy link
Contributor

bors-servo commented Nov 3, 2016

The build was interrupted to prioritize another pull request.

@bors-servo
Copy link
Contributor

bors-servo commented Nov 3, 2016

Testing commit 53b638c with merge 5b4cc95...

bors-servo added a commit that referenced this pull request Nov 3, 2016
Update to string-cache 0.3

Previously, `string-cache` defined:
*  An string-like `Atom` type,
* An `atom!("foo")` macro that expands to a value of that type, for a set of strings known at compile-time,
* A `struct Namespace(Atom);` type
* A `ns!(html)` macro that maps known prefixed to `Namespace` values with the corresponding namespace URL.

Adding a string to the static set required making a change to the `string-cache` crate.

With 0.3, the `Atom` type is now generic, with a type parameter that provides a set of static strings. We can have multiple such sets, defined in different crates. The `string_cache_codegen` crate, to be used in build scripts, generates code that defines such a set, a new atom type (a type alias for `Atom<_>` with the type parameter set), and an `atom!`-like macro.

The html5ever repository has a new `html5ever_atoms` crate that defines three such types: `Prefix`, `Namespace`, and `LocalName` (with respective `namespace_prefix!`, `namespace_url!`, and `local_name!` macros). It also defines the `ns!` macro like before.

This repository has a new `servo_atoms` crate in `components/atoms` that, for now, defines a single `Atom` type (and `atom!`) macro. (`servo_atoms::Atom` is defined as something like `type Atom = string_cache::Atom<ServoStaticStringSet>;`, so overall there’s now two types named `Atom`.)

In this PR, `servo_atoms::Atom` is used for everything else that was `string_cache::Atom` before. But more atom types can be defined as needed. Two reasons to do this are to auto-generate the set of static strings (I’m planning to do this for CSS property names, which is the motivation for this change), or to have the type system help us avoid mix up unrelated things (this is why we had a `Namespace` type ever before this change).

Introducing new types helped me find a bug: when creating a new attribute `dom::Element::set_style_attr`, would pass `Some(atom!("style"))` instead of `None` (now `Option<html5ever_atoms::Prefix>` instead of `Option<string_cache::Atom>`) to the `prefix` argument of `Attr::new`. I suppose the author of that code confused it with the `local_name` argument.

---

Note that Stylo is not affected by any of this. The `gecko_string_cache` module is unchanged, with a single `Atom` type. The `style` crate conditionally compiles `Prefix` and `LocalName` re-exports for that are both `gecko_string_cache::Atom` on stylo.

---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).

<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____

<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/14043)
<!-- Reviewable:end -->
@bors-servo
Copy link
Contributor

bors-servo commented Nov 3, 2016

@bors-servo bors-servo merged commit 53b638c into master Nov 3, 2016
2 of 4 checks passed
2 of 4 checks passed
continuous-integration/appveyor/pr AppVeyor build failed
Details
dependency-ci Failed dependency checks
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants
You can’t perform that action at this time.