Bug 1476445 - Use an acquire load for is_unique in servo_arc. r=manishearth MozReview-Commit-ID: Dv7Rql4KUgr Differential Revision: https://phabricator.services.mozilla.com/D2205

Bug 1459367 - Convert NS_STYLE_IMAGELAYER_ATTACHMENT_* to enum class. r=manishearth Converted NS_STYLE_IMAGELAYER_ATTATCHMENT_* vals to enum class, StyleImageLayerAttachment.

Bug 1455784 - Update StyleSource to use ArcUnion. r=Manishearth MozReview-Commit-ID: AT4sud9goGV

Bug 1455784 - ArcUnion. r=Manishearth MozReview-Commit-ID: Jxp2A7cj6CV

servo: Merge #20603 - Run rustfmt on selectors, servo_arc, and style (from bholley:rustfmt_style); r=Manishearth Now that rustfmt is getting close to stable, and work on the style system has died down a bit, it seemed like an opportune time to auto-format the style crates. The first commit disables import reordering, since tidy and rustfmt don't currently agree on the correct ordering. The second commit does a bunch of manual fixups such that the output of rustfmt passes tidy. The third commit runs rustfmt on the three aforementioned crate. There are a few dozen warnings in the style crate about lines longer than 100 characters. It would be good to fix these, but I don't have time for that now. Source-Repo: https://github.com/servo/servo Source-Revision: 9a900ef019cd643bff961d7b20db6da69f3edb29

servo: Merge #20598 - Four nondescript WebGL improvements (from servo:webgl); r=Manishearth Source-Repo: https://github.com/servo/servo Source-Revision: ce72e526566de70ed71684ebc39a531f59c92aa5

servo: Merge #20247 - Stop unconditionally collecting traversal statistics in nightly builds (from bholley:fix_stat_collection); r=Manishearth The current code also makes us panic when DUMP_STYLE_STATISTICS=1 is set. :-( Source-Repo: https://github.com/servo/servo Source-Revision: 4c797dfb5239c5e9a4014e91ed121ef9cf641ad0

servo: Merge #20210 - style: Add a comment about the weird setup for justify-items (from emilio:justify-items-kinda-sucks); r=Manishearth And derive ToCss while at it. Source-Repo: https://github.com/servo/servo Source-Revision: 226d9a5b0e69185b95c62e79b81044beba477654

servo: Merge #20135 - Clean up after some disk-space intensive builds (from servo:jdm-patch-13); r=Manishearth This should help the ongoing disk usage problems. Source-Repo: https://github.com/servo/servo Source-Revision: 068c1eb9fbff43bcf089c7c27101c72ef205b0c8

Bug 1438811: Remove the remaining bits of the traversal telemetry stuff. r?Manishearth MozReview-Commit-ID: 2dA5usbGQRt

Bug 1438811: Remove the remaining bits of the traversal telemetry stuff. r=manishearth MozReview-Commit-ID: 2dA5usbGQRt

Bug 1438811: Remove the remaining bits of the traversal telemetry stuff. r?Manishearth MozReview-Commit-ID: 2dA5usbGQRt

Bug 1438811: Remove the remaining bits of the traversal telemetry stuff. r?Manishearth MozReview-Commit-ID: 2dA5usbGQRt

Bug 1438811: Remove the remaining bits of the traversal telemetry stuff. r?Manishearth MozReview-Commit-ID: 2dA5usbGQRt

Bug 1438811: Remove the remaining bits of the traversal telemetry stuff. r?Manishearth MozReview-Commit-ID: 2dA5usbGQRt

servo: Merge #20011 - style: Tidy Stylist::compute_for_declarations (from emilio:cleanup-for-declarations-stuff); r=Manishearth Source-Repo: https://github.com/servo/servo Source-Revision: 0098d519030f395f94f3f82fc04b93227fdff4ec

Bug 1423840 (attempt 2) - Rewrite the prefs parser. r=glandium,Manishearth The prefs parser has two significant problems. - It doesn't separate tokenizing from parsing. - It is implemented as a loop around a big switch on a "current state" variable. As a result, it is hard to understand and modify, slower than it could be, and in obscure cases (involving comments and whitespace) it fails to parse what should be valid input. This patch replaces it with a recursive descent parser (albeit one without any recursion!) that has separate tokenization. The new parser is easier to understand and modify, more correct, and has better error messages. It doesn't do error recovery, but that would be much easier to add than in the old parser. The new parser also runs about 1.9x faster than the existing parser. (As measured by parsing greprefs.js's contents from memory 1000 times in succession, omitting the prefs hash table construction. If the table construction is included, it's about 1.6x faster.) The new parser is slightly stricter than the old parser in a few ways. - Disconcertingly, the old parser allowed arbitrary junk between prefs (including at the start and end of the prefs file) so long as that junk didn't include any of the following chars: '/', '#', 'u', 's', 'p'. I.e. lines like these: !foo@bar&pref("prefname", true); ticky_pref("prefname", true); // missing 's' at start User_pref("prefname", true); // should be 'u' at start would all be treated the same as this: pref("prefname", true); The new parser disallows such junk because it isn't necessary and seems like an unintentional botch by the old parser. - The old parser allowed character 0x1a (SUB) between tokens and treated it like '\n'. The new parser does not allow this character. SUB was used to indicate end-of-file (*not* end-of-line) in some old operating systems such as MS-DOS, but this doesn't seem necessary today. - The old parser tolerated (with a warning) invalid escape sequences within string literals -- such as "\q" (not a valid escape) and "\x1" and "\u12" (both of which have insufficient hex digits) -- accepting them literally. The new parser does not tolerate invalid escape sequences because it doesn't seem necessary and would complicate things. - The old parser tolerated character 0x00 (NUL) within string literals; this is dangerous because C++ code that manipulates string values with embedded NULs will almost certainly consider those chars as end-of-string markers. The new parser treats NUL chars as end-of-file, to avoid this danger and because it facilitates a significant optimization (described within the code). - The old parser allowed integer literals to overflow, silently wrapping them. The new parser treats integer overflow as a parse error. This seems better, and it caught existing overflows of places.database.lastMaintenance, in testing/profiles/prefs_general.js (bug 1424030) and testing/talos/talos/config.py (bug 1434813). The first of these changes meant that a couple of existing prefs with ";;" at the end had to be changed (done in the preceding patch). The minor increase in strictness shouldn't be a problem for default pref files such as greprefs.js within the application (which we can modify), nor for app-written prefs files such as prefs.js. It could affect user-written prefs files such as user.js; the experience above suggests that integer overflow and ";;" are the most likely problems in practice. In my opinion, the risk here is acceptable. The new parser also does a better job of tracking line numbers because it (a) treats "\r\n" sequences as a single end-of-line marker, and (a) pays attention to end-of-line sequences within string literals. Finally, the patch adds thorough tests of both valid and invalid syntax. MozReview-Commit-ID: JD3beOQl4AJ

servo: Merge #19912 - style: Temporarily use OrderMap on Gecko (from emilio:ordermap); r=Manishearth This will allow us to discard std hash map as a source of crashes. Source-Repo: https://github.com/servo/servo Source-Revision: e6d9c251d1b9770aa520bf358b79d906a00d71bb

Bug 1423840 - Rewrite the prefs parser. r=glandium,Manishearth The prefs parser has two significant problems. - It doesn't separate tokenizing from parsing. - It is implemented as a loop around a big switch on a "current state" variable. As a result, it is hard to understand and modify, slower than it could be, and in obscure cases (involving comments and whitespace) it fails to parse what should be valid input. This patch replaces it with a recursive descent parser (albeit one without any recursion!) that has separate tokenization. The new parser is easier to understand and modify, more correct, and has better error messages. It doesn't do error recovery, but that would be much easier to add than in the old parser. The new parser also runs about 1.9x faster than the existing parser. (As measured by parsing greprefs.js's contents from memory 1000 times in succession, omitting the prefs hash table construction. If the table construction is included, it's about 1.6x faster.) The new parser is slightly stricter than the old parser in a few ways. - Disconcertingly, the old parser allowed arbitrary junk between prefs (including at the start and end of the prefs file) so long as that junk didn't include any of the following chars: '/', '#', 'u', 's', 'p'. I.e. lines like these: !foo@bar&pref("prefname", true); ticky_pref("prefname", true); // missing 's' at start User_pref("prefname", true); // should be 'u' at start would all be treated the same as this: pref("prefname", true); The new parser disallows such junk because it isn't necessary and seems like an unintentional botch by the old parser. - The old parser allowed character 0x1a (SUB) between tokens and treated it like '\n'. The new parser does not allow this character. SUB was used to indicate end-of-file (*not* end-of-line) in some old operating systems such as MS-DOS, but this doesn't seem necessary today. - The old parser tolerated (with a warning) invalid escape sequences within string literals -- such as "\q" (not a valid escape) and "\x1" and "\u12" (both of which have insufficient hex digits) -- accepting them literally. The new parser does not tolerate invalid escape sequences because it doesn't seem necessary and would complicate things. - The old parser tolerated character 0x00 (NUL) within string literals; this is dangerous because C++ code that manipulates string values with embedded NULs will almost certainly consider those chars as end-of-string markers. The new parser treats NUL chars as end-of-file, to avoid this danger and because it facilitates a significant optimization (described within the code). - The old parser allowed integer literals to overflow, silently wrapping them. The new parser treats integer overflow as a parse error. This seems better, and it caught an existing overflow in testing/profiles/prefs_general.js, for places.database.lastMaintenance (see bug 1424030). The first of these changes meant that a couple of existing prefs with ";;" at the end had to be changed (done in the preceding patch). The minor increase in strictness shouldn't be a problem for default pref files such as greprefs.js within the application (which we can modify), nor for app-written prefs files such as prefs.js. It could affect user-written prefs files such as user.js; the experience above suggests that ";;" is the most likely problem in practice. In my opinion, the risk here is acceptable. The new parser also does a better job of tracking line numbers because it (a) treats "\r\n" sequences as a single end-of-line marker, and (a) pays attention to end-of-line sequences within string literals. Finally, the patch adds thorough tests of both valid and invalid syntax. MozReview-Commit-ID: 8EYWH7KxGG * * * [mq]: win-fix MozReview-Commit-ID: 91Bxjfghqfw

servo: Merge #19864 - Make some callback-related code unsafe (from nox:callbacks); r=Manishearth Source-Repo: https://github.com/servo/servo Source-Revision: e9ab91d257a983a7c19cb5fada21a0359cfae95d

Bug 1431031: Tests for calc() on font-size on various situations. r=Manishearth It makes no sense to pass a custom base size of zero in presence of rem, ex, or ch units. MozReview-Commit-ID: 7ZZwRzQKREX

servo: Merge #19807 - style: Make the Gecko font-size calc() code do what it means to do (from emilio:calc-font-size); r=Manishearth It makes no sense to pass a custom base size of zero in presence of rem, ex, or ch units. Bug: 1431031 Reviewed-by: Manishearth MozReview-Commit-ID: 7ZZwRzQKREX Source-Repo: https://github.com/servo/servo Source-Revision: 671b69c0b77f9a4bd0c098cb2a2f73c95dacb954

Bug 1431031: Don't use reference_font_size for resolving rem on the root element. r?Manishearth ReferenceFontSize::InheritedStyle and ReferenceFontSize::CurrentStyle are fine, because they're by definition the initial font-size on the root at that point. The font-size Calc code passes ReferenceFontSize::Custom(0) to strip out the relative part, but that has the unfortunate effect of stripping rem units on the root. Prevent that by using always the inherited style, which is always the reset style. MozReview-Commit-ID: 7ZZwRzQKREX

Bug 1431031: Don't use reference_font_size for resolving rem on the root element. r?Manishearth ReferenceFontSize::InheritedStyle and ReferenceFontSize::CurrentStyle are fine, because they're by definition the initial font-size on the root at that point. The font-size Calc code passes ReferenceFontSize::Custom(0) to strip out the relative part, but that has the unfortunate effect of stripping rem units on the root. Prevent that by using always the inherited style, which is always the reset style. MozReview-Commit-ID: 7ZZwRzQKREX

servo: Merge #19665 - style_derive: Support parse-time aliases (from emilio:derive-parse-alias); r=Manishearth This will allow #19659 to use derive on display using: #[parse(aliases = "-webkit-flex")] Flex, #[parse(aliases = "-webkit-inline-flex")] InlineFlex, And such. Source-Repo: https://github.com/servo/servo Source-Revision: 4ba795081cd1efa42ce03c996d574cfe96f68ece

servo: Merge #19576 - style: Move text-align outside of the mako file (from canaltinova:text-align); r=Manishearth,emilio I will need this refactoring before my next job. I didn't actually fix the FIXME's along the way. My other PR probably will cover these. --- - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors Source-Repo: https://github.com/servo/servo Source-Revision: a9c17970c19a993920ce1ba2ff9faebd033c52b4

Bug 1423840 - Rewrite the prefs parser. r=glandium,Manishearth The prefs parser has two significant problems. - It doesn't separate tokenizing from parsing. - It is implemented as a loop around a big switch on a "current state" variable. As a result, it is hard to understand and modify, slower than it could be, and in obscure cases (involving comments and whitespace) it fails to parse what should be valid input. This patch replaces it with a recursive descent parser (albeit one without any recursion!) that has separate tokenization. The new parser is easier to understand and modify, more correct, and has better error messages. It doesn't do error recovery, but that would be much easier to add than in the old parser. The new parser also runs about 1.9x faster than the existing parser. (As measured by parsing greprefs.js's contents from memory 1000 times in succession, omitting the prefs hash table construction. If the table construction is included, it's about 1.6x faster.) The new parser is slightly stricter than the old parser in a few ways. - Disconcertingly, the old parser allowed arbitrary junk between prefs (including at the start and end of the prefs file) so long as that junk didn't include any of the following chars: '/', '#', 'u', 's', 'p'. I.e. a line like this: !foo@bar&pref("prefname", true); ticky_pref("prefname", true); // missing 's' at start User_pref("prefname", true); // should be 'u' at start would be treated the same as this: pref("prefname", true); The new parser disallows such junk because it isn't necessary and seems like an unintentional botch by the old parser. - The old parser allowed character 0x1a (SUB) between tokens and treated it like '\n'. The new parser does not allow this character. SUB was used to indicate end-of-file (*not* end-of-line) in some old operating systems such as MS-DOS, but this doesn't seem necessary today. - The old parser tolerated (with a warning) invalid escape sequences within string literals -- such as "\q" (not a valid escape) and "\x1" and "\u12" (both of which have insufficient hex digits) -- accepting them literally. The new parser does not tolerates invalid escape sequences because it doesn't seem necessary and would complicate things. - The old parser tolerated character 0x00 (NUL) within string literals; this is dangerous because C++ code that manipulates string values with embedded NULs will almost certainly consider those chars as end-of-string markers. The new parser treats NUL chars as end-of-file, to avoid this danger and because it facilitates a significant optimization (described within the code). - The old parser allowed integer literals to overflow, silently wrapping them. The new parser treats integer overflow as a parse error. This seems better, and it caught an existing overflow in testing/profiles/prefs_general.js, for places.database.lastMaintenance (see bug 1424030). The first of these changes meant that a couple of existing prefs with ";;" at the end had to be changed. The minor increase in strictness shouldn't be a problem for default pref files such as greprefs.js within the application (which we can modify), nor for app-written prefs files such as prefs.js. It could affect user-written prefs files such as user.js; the experience above suggests that ";;" is the most likely problem in practice. In my opinion, the risk here is acceptable. The new parser also does a better job of tracking line numbers because it (a) treats "\r\n" sequences as a single end-of-line marker, and (a) pays attention to end-of-line sequences within string literals. Finally, the patch adds thorough tests of both valid and invalid syntax. MozReview-Commit-ID: 8EYWH7KxGG

servo: Merge #19578 - Allow deriving Parse on keywords (from emilio:parse-keyword); r=Manishearth,canaltinova This makes patches like #19576 much easier. Source-Repo: https://github.com/servo/servo Source-Revision: e631d167bf28676e45e37f418b4282fcfba98c1e

Bug 1423840 - Rewrite the prefs parser. r=glandium,Manishearth The prefs parser has two significant problems. - It doesn't separate tokenizing from parsing. - It is implemented as a loop around a big switch on a "current state" variable. As a result, it is hard to understand and modify, slower than it could be, and in obscure cases (involving comments and whitespace) it fails to parse what should be valid input. This patch replaces it with a recursive descent parser (albeit one without any recursion!) that has separate tokenization. The new parser is easier to understand and modify, more correct, and has better error messages. It doesn't do error recovery, but that would be much easier to add than in the old parser. The new parser also runs about 1.9x faster than the existing parser. (As measured by parsing greprefs.js's contents from memory 1000 times in succession, omitting the prefs hash table construction. If the table construction is included, it's about 1.6x faster.) The new parser is slightly stricter than the old parser in a few ways. - Disconcertingly, the old parser allowed arbitrary junk between prefs (including at the start and end of the prefs file) so long as that junk didn't include any of the following chars: '/', '#', 'u', 's', 'p'. I.e. a line like this: !foo@bar&pref("prefname", true); ticky_pref("prefname", true); // missing 's' at start User_pref("prefname", true); // should be 'u' at start would be treated the same as this: pref("prefname", true); The new parser disallows such junk because it isn't necessary and seems like an unintentional botch by the old parser. - The old parser allowed character 0x1a (SUB) between tokens and treated it like '\n'. The new parser does not allow this character. SUB was used to indicate end-of-file (*not* end-of-line) in some old operating systems such as MS-DOS, but this doesn't seem necessary today. - The old parser tolerated (with a warning) invalid escape sequences within string literals -- such as "\q" (not a valid escape) and "\x1" and "\u12" (both of which have insufficient hex digits) -- accepting them literally. The new parser does not tolerates invalid escape sequences because it doesn't seem necessary and would complicate things. - The old parser tolerated character 0x00 (NUL) within string literals; this is dangerous because C++ code that manipulates string values with embedded NULs will almost certainly consider those chars as end-of-string markers. The new parser treats NUL chars as end-of-file, to avoid this danger and because it facilitates a significant optimization (described within the code). - The old parser allowed integer literals to overflow, silently wrapping them. The new parser treats integer overflow as a parse error. This seems better, and it caught an existing overflow in testing/profiles/prefs_general.js, for places.database.lastMaintenance (see bug 1424030). The first of these changes meant that a couple of existing prefs with ";;" at the end had to be changed. The minor increase in strictness shouldn't be a problem for default pref files such as greprefs.js within the application (which we can modify), nor for app-written prefs files such as prefs.js. It could affect user-written prefs files such as user.js; the experience above suggests that ";;" is the most likely problem in practice. In my opinion, the risk here is acceptable. The new parser also does a better job of tracking line numbers because it (a) treats "\r\n" sequences as a single end-of-line marker, and (a) pays attention to end-of-line sequences within string literals. Finally, the patch adds thorough tests of both valid and invalid syntax. MozReview-Commit-ID: 8EYWH7KxGG

Bug 1423840 - Rewrite the prefs parser. r=glandium,Manishearth The prefs parser has two significant problems. - It doesn't separate tokenizing from parsing. - It is implemented as a loop around a big switch on a "current state" variable. As a result, it is hard to understand and modify, slower than it could be, and in obscure cases it fails to parse some valid input. This patch replaces it with a recursive descent parser (albeit one without any recursion!) that has separate tokenization. The new parser is easier to understand and modify, more correct, and has better error messages (including filenames). It also runs about 1.9x faster than the existing parser. (As measured by parsing greprefs.js's contents from memory 1000 times in succession, omitting the prefs hash table construction. If the table construction is included, it's about 1.6x faster.) The new parser is slightly stricter than the old parser in a few ways. - Disconcertingly, the old parser allowed arbitrary junk between prefs (including at the start and end of the prefs file) so long as that junk didn't include any of the following chars: '/', '#', 'u', 's', 'p'. I.e. a line like this: !foo@bar&pref("prefname", true); would be treated the same as this: pref("prefname", true); The new parser disallows such junk because it isn't necessary and seems like an unintentional botch by the old parser. - The old parser allowed character 0x1a (SUB) between tokens and treated it like '\n'. The new parser does not allow this character. SUB was used to indicate end-of-file (*not* end-of-line) in some old operating systems such as MS-DOS, but this doesn't seem necessary today. - The old parser tolerated (with a warning) invalid escape sequences within string literals -- such as "\q" (not a valid escape) and "\x1" and "\u12" (both of which have insufficient hex digits) -- accepting them literally. The new parser does not tolerates invalid escape sequences because it doesn't seem necessary and would complicate things. - The old parser tolerated character 0x00 (NUL) within string literals; this is dangerous because C++ code that manipulates string values with embedded NULs will almost certainly consider those chars as end-of-string markers. The new parser treats NUL chars as end-of-file, to avoid this danger and because it facilitates a significant optimization (described within the code). - The old parser allowed integer literals to overflow, silently wrapping them. The new parser treats integer overflow as a parse error. This seems better, and it caught an existing overflow in testing/profiles/prefs_general.js, for places.database.lastMaintenance. The first of these changes meant that a couple of existing prefs with ";;" at the end had to be changed. The minor increase in strictness shouldn't be a problem for default pref files such as greprefs.js within the application (which we can modify), nor for app-written prefs files such as prefs.js. It could affect user-written prefs files such as user.js; the experience above suggests that ";;" is the most likely problem in practice. In my opinion, the risk here is acceptable. The new parser should also do a better job of tracking line numbers because it (a) treats "\r\n" sequences as a single end-of-line marker, and (a) pays attention to end-of-line sequences within string literals. The patch also adds a thorough test of valid syntax. (Note that the old parser fails to correctly parse this test in a few places because it misimplemented the grammar.) I'd like to also add tests for invalid syntax but the current design makes this challenging, because parse errors trigger an error message on the web console and a NS_ERROR_FILE_CORRUPTED return value from Parse(). MozReview-Commit-ID: 8EYWH7KxGG

Bug 1423840 - Rewrite the prefs parser. r=glandium,Manishearth The prefs parser has two significant problems. - It doesn't separate tokenizing from parsing. - It is implemented as a loop around a big switch on a "current state" variable. As a result, it is hard to understand and modify, slower than it could be, and in obscure cases it fails to parse some valid input. This patch replaces it with a recursive descent parser (albeit one without any recursion!) that has separate tokenization. The new parser is easier to understand and modify, more correct, and has better error messages (including filenames). It also runs about 1.9x faster than the existing parser. (As measured by parsing greprefs.js's contents from memory 1000 times in succession, omitting the prefs hash table construction. If the table construction is included, it's about 1.4x faster.) The new parser is slightly stricter than the old parser in a few ways. - Disconcertingly, the old parser allowed arbitrary junk between prefs (including at the start and end of the prefs file) so long as that junk didn't include any of the following chars: '/', '#', 'u', 's', 'p'. I.e. a line like this: !foo@bar&pref("prefname", true); would be treated the same as this: pref("prefname", true); The new parser disallows such junk because it isn't necessary and seems like an unintentional botch by the old parser. - The old parser allowed character 0x1a (SUB) between tokens and treated it like '\n'. The new parser does not allow this character. SUB was used to indicate end-of-file (*not* end-of-line) in some old operating systems such as MS-DOS, but this doesn't seem necessary today. - The old parser tolerated (with a warning) invalid escape sequences within string literals -- such as "\q" (not a valid escape) and "\x1" and "\u12" (both of which have insufficient hex digits) -- accepting them literally. The new parser does not tolerates invalid escape sequences because it doesn't seem necessary and would complicate things. - The old parser tolerated character 0x00 (NUL) within string literals; this is dangerous because C++ code that manipulates string values with embedded NULs will almost certainly consider those chars as end-of-string markers. The new parser treats NUL chars as end-of-file, to avoid this danger and because it facilitates a significant optimization (described within the code). - The old parser allowed integer literals to overflow, silently wrapping them. The new parser treats integer overflow as a parse error. This seems better, and it caught an existing overflow in testing/profiles/prefs_general.js, for places.database.lastMaintenance. The first of these changes meant that a couple of existing prefs with ";;" at the end had to be changed. The minor increase in strictness shouldn't be a problem for default pref files such as greprefs.js within the application (which we can modify), nor for app-written prefs files such as prefs.js. It could affect user-written prefs files such as user.js; the experience above suggests that ";;" is the most likely problem in practice. In my opinion, the risk here is acceptable. The new parser should also do a better job of tracking line numbers because it (a) treats "\r\n" sequences as a single end-of-line marker, and (a) pays attention to end-of-line sequences within string literals. The patch also adds a thorough test of valid syntax. (Note that the old parser fails to correctly parse this test in a few places because it misimplemented the grammar.) I'd like to also add tests for invalid syntax but the current design makes this challenging, because parse errors trigger an error message on the web console and a NS_ERROR_FILE_CORRUPTED return value from Parse(). MozReview-Commit-ID: 8EYWH7KxGG

Bug 1422641: Inline Gecko_GetSMILOverrideDeclarationBlock. r?Manishearth,xidorn MozReview-Commit-ID: E8cM7zRZHn1

Bug 1422641: Inline Gecko_GetSMILOverrideDeclarationBlock. r=Manishearth,xidorn MozReview-Commit-ID: E8cM7zRZHn1

servo: Merge #19493 - style: Some stylo-chrome perf tweaks (from emilio:chrome-perf); r=xidorn,Manishearth Source-Repo: https://github.com/servo/servo Source-Revision: 8f30880d362ef54a2c6881c4927b96303ff763ef

Bug 1422641: Inline Gecko_GetSMILOverrideDeclarationBlock. r?Manishearth,xidorn MozReview-Commit-ID: E8cM7zRZHn1

Bug 1422641: Inline Gecko_GetSMILOverrideDeclarationBlock. r?Manishearth,xidorn MozReview-Commit-ID: E8cM7zRZHn1

Bug 1422641: Inline Gecko_GetSMILOverrideDeclarationBlock. r?Manishearth,xidorn MozReview-Commit-ID: E8cM7zRZHn1

Bug 1408308: Integrate Servo SourceSizeList in ResponsiveImageSelector. r=Manishearth MozReview-Commit-ID: DMVfE56DyYm

Bug 1408308: Integrate Servo SourceSizeList in ResponsiveImageSelector. r=Manishearth This needs to dumb down the parsing in order to match what we do in Gecko and pass more tests. The remaining tests are just because of calc() in media queries and "or" media expressions. MozReview-Commit-ID: CXGdYVbojBL

servo: Merge #19197 - stylo: Integrate Servo SourceSizeList in ResponsiveImageSelector (from emilio:source-size-list-integration); r=Manishearth Bug: 1408308 Reviewed-by: Manishearth Source-Repo: https://github.com/servo/servo Source-Revision: 5d3a90ecce766f3dfba35e08101a74a5d73dba79

Bug 1396057: Change tests of calc in media-queries so that the root element style has been resolved first. r=Manishearth This modify the tests so that the media query evaluation they're testing happens after style resolution, which would've caught a bug in rem unit evaluation inside media queries in stylo. MozReview-Commit-ID: ByaR4ZA995l

servo: Merge #19194 - stylo: Bring back support for calc() in media-queries (from emilio:media-query-calc); r=Manishearth Bug: 1396057 Reviewed-by: Manishearth Source-Repo: https://github.com/servo/servo Source-Revision: 4970b5d1544fe8f33287b01540e972a639baa689

servo: Merge #16946 - Add intermittent failure reporting to filter-intermittents (from jdm:report); r=Manishearth We need to address https://github.com/servo/saltfs/issues/671 before this can be enabled by default on the builders, but I got the pieces working locally. This collects relevant information about each recorded intermittent failure encountered during a test run and posts them to a webapp which stores them in a database for later investigation. This will allow us to track over time which intermittent test failures are the most frequent, as well as whether they only happen on a particular builder or operating system. Source-Repo: https://github.com/servo/servo Source-Revision: 693c3dcfb29ecc2aa4610aabc68ce7381bfd5d87

Bug 1412743 - style: Avoid double-applying text-zoom for keywords. r=Manishearth, a=ritu Source-Repo: https://github.com/servo/servo Source-Revision: c882266c8915b9f424cc4efbc860a9e417bf1326

servo: Merge #19074 - style: Avoid double-applying text-zoom for keywords (from emilio:font-size-woes); r=Manishearth Bug: 1412743 Reviewed-by: Manishearth Source-Repo: https://github.com/servo/servo Source-Revision: c882266c8915b9f424cc4efbc860a9e417bf1326

Bug 1412743: Avoid double-applying text-zoom for keywords. r?Manishearth MozReview-Commit-ID: 3iOstV6RifQ

Bug 1412743: Avoid double-applying text-zoom for keywords. r?Manishearth MozReview-Commit-ID: 3iOstV6RifQ

Bug 1412868: Remove Gecko_GetLookAndFeelSystemColor from the static analysis whitelist. r=manishearth MozReview-Commit-ID: 7gf3CZM3ypv

servo: Merge #19055 - Add support for -moz-window-opacity to stylo (from upsuper:window-opacity); r=Manishearth Fixes [bug 1374177](https://bugzilla.mozilla.org/show_bug.cgi?id=1374177). Source-Repo: https://github.com/servo/servo Source-Revision: 17bfe5c12013a47c09e0198d029f3ded2ccbc42c

Bug 1409444 - Update rand to 0.3.17. r=manishearth a=ritu