We can no longer use direction overrides to create the test vs reference renderings here,
because of how harfbuzz now handles the numeral directionality internally. So it's difficult
to come up with a testcase that verifies the exact rendering of the subtending mark + digit(s)
combinations.
What we can do, though, is verify that a single digit combines with the subtending mark
without affecting its overall width; and that a double-digit number *does* increase the
width. These two conditions are unlikely to both hold unless the rendering is behaving
correctly.
(FWIW, Chrome Canary passes these new test versions, as it also uses a recent harfbuzz;
Safari currently fails, as Core Text doesn't support the subtending marks in the same
way, if at all.)
Differential Revision: https://phabricator.services.mozilla.com/D124902
As discussed in https://bugzilla.mozilla.org/show_bug.cgi?id=1719747#c6,
In Part 1, the ownership of the Span in PartsVector is maintained by
ICU. This method adds a callback so js::intl::ListFormat could copy the
content of the Span to Spidermonkey, and mozilla::intl::ListFormat could
use ScopedICUObject to release the string owned by ICU earlier.
Differential Revision: https://phabricator.services.mozilla.com/D123166
Currently IONFLAGS=codegen doesn't show the assembler offset on any target,
AFAIK. On arm64, at least, reasoning about code offsets merely by looking at
the log output is unreliable, because it is impossible to spot "holes"
(multiple 4-byte insn slots) in the output, and also it is impossible to see
where there has been a transition to a new assembler instance.
This patch fixes it in the obvious way, by printing the offset as 6 hex
digits. Before:
[Codegen] [3] f8408780 ldr x0, [x28], #8
[Codegen] [3] f85c02e9 ldur x9, [x23, #-64]
After:
[Codegen] [3] 00b280 f8408780 ldr x0, [x28], #8
[Codegen] [3] 00b284 f85c02e9 ldur x9, [x23, #-64]
Differential Revision: https://phabricator.services.mozilla.com/D125050
This gets rid of some more platform ifdefs and reorganizes the functions and comments
to more naturally reflect their functional group. No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D124808
This is a fairly large refactor without any change intended in
functionality or even (functionality-neutral) code generation.
Background:
Previously, atomic operations were split into several parts that lived
in different parts of WasmBaselineCompile.cpp and WasmBCMemory.cpp:
* the "emitters" in WasmBaselineCompile.cpp which read bytecode and
called code generation functions in WasmBCMemory.cpp;
* the code generation drivers in WasmBCMemory.cpp such as atomicXchg();
* the "poppers", which were RAII wrappers that would know about how to
do register allocation and assignment per-platform;
* a helper class for managing temp registers separately from the
poppers, defined in WasmBCMemory.h; and
* template functions that would drive the macroassembler given the
inputs from the above.
Historically these were scattered far apart in WasmBaselineCompile.cpp
because of the layering of that file; the recent refactor just moved
some of them to WasmBCMemory.cpp without doing anything more.
This patch changes the structure as follows:
* the "emitters" stay where they are because they are clean and
because separating out the emitters is a good pattern we want to
continue to use; and
* the other parts have been brought together in WasmBCMemory.cpp and
ifdeffed in a way that keeps related code together.
In particular, the code generation drivers now have a common form,
where it explicitly calls pop/alloc, codegen, and dealloc methods, and
the methods for an operation on a platform are defined together. This
should make code significantly more maintainable, and it reduces the
ifdeffery in the file. Also it allows the file to be organized
better.
Differential Revision: https://phabricator.services.mozilla.com/D124645
WasmBCMemory.h held a class that was visible in WasmBCClass.h, but
this class can be internal to WasmBCMemory.cpp if some of the methods
on BaseCompiler are turned into static functions in the latter file.
Differential Revision: https://phabricator.services.mozilla.com/D124643
Remove platform dependencies that depend only on whether the platform
has a HeapReg or not, by introducing a properly named #define for this
and rewriting the code slightly.
Introduce a RegIntptr alias to express integer-representing-pointer
appropriately on different platforms.
Introduce a templated move() method for register-to-register moves.
Drive-by cleanup:
Replace the overloaded free() methods for freeing registers with a
templated variant to match what we have for push, pop, need, and move.
Document the internal #defines that control the compiler.
Differential Revision: https://phabricator.services.mozilla.com/D124642
X11 tries to convert any binary clipboard data to text if text MIME type is missing in clipboard.
This leads to various errors, wrong conversions and timeouts.
So get clipboard content first and if there are only binary MIME types in clipboard advertise only these types.
Differential Revision: https://phabricator.services.mozilla.com/D123687
This adds a test that goes through all combinations of a number of important features, and verifies that the JSON output looks valid.
Differential Revision: https://phabricator.services.mozilla.com/D124739
All profiles submitted to `JSONOutputCheck` are now checked for valid-looking samples, as in:
- Samples should point into the stackTable.
- stackTable entries should point to the caller in the same stackTable (or null for the root frame).
- stackTable entries should also point into the frameTable.
- frameTable entries should point into the stringTable for the "location".
Differential Revision: https://phabricator.services.mozilla.com/D124738
A scenario for a thread may be that the first entry has an empty sample (usually if stack-sampling is turned off) and no running times (first-ever sample, or "cpu" is off), so it's not output, and there is no corresponding stack table entry.
Then there may be a "same sample" entry.
- If there are no running times, nothing should be output.
- If there are running times, an empty stack should be output, but for that we need to ensure that the root frame is present in the stack table entry, because that represents an empty stack.
Differential Revision: https://phabricator.services.mozilla.com/D124612
Turns out my patch above causes some failures because chrome:// channels
don't have cache information, so we conservatively assume they always
expire, which causes some interesting timing issues in a single test.
Fun stuff.
Tweak the code so that SubresourceCacheValidationInfo has the
pre-existing data:// URI special-case and also special-cases chrome://
URIs.
Differential Revision: https://phabricator.services.mozilla.com/D124921
Tetsuharu Ohzeki
Jesse Schwartzentruber
Kris Wright
Benjamin Peterson
Greg Tatum
Andrew Halberstadt
Jonathan Kew
Ryan VanderMeulen
ffxbld
Mark Banner
Andrei Oprea
Edgar Chen
Cristian Tuns
Eden Chuang
Jan de Mooij
Florian Quèze
Lars T Hansen
Joel Maher
Yoshi Cheng-Hao Huang
Julian Seward
stransky
Gerald Squelart
Emilio Cobos Álvarez
hxu
Paul Bone
Geoff Lankow
Mirko Brodesser
Kershaw Chang