| Age | Commit message (Collapse) | Author |
|---|
|
There is no use to create a temporary String of a char const* to just
cast it to a StringView on SysFSComponent construction again.
Also this could have lead to a UAF bug.
|
|
|
|
|
|
|
|
A5A8-A5D1 https://www.unicode.org/charts/PDF/UA500.pdf
|
|
This allows us to see which custom properties apply to a given element,
which previously wasn't shown.
|
|
|
|
|
|
Now that LibUnicode generates these patterns, the AO steps to retrieve
them may be implemented.
|
|
In a future commit, the "part" view returned from FormatDateTimePattern
may be a view into a string that goes out of scope. Ensure the AO only
returns valid views. A similar approach is used in Intl.NumberFormat.
|
|
The fields of the generated elements must be in the same order as the
table here:
https://unicode.org/reports/tr35/tr35-dates.html#Date_Field_Symbol_Table
Further, only one field from each group of fields is allowed.
|
|
|
|
Pattern skeletons are more or less the "key" of format patterns. Every
format pattern is assigned a skeleton. Interval patterns (which are not
yet parsed) are also assigned a skeleton - this is used to match them to
an "owning" format pattern. So we will use the skeleton generated here
to match format patterns at runtime with their available interval
patterns.
An alternative approach would be to append interval patterns directly to
their owning format pattern, but this has some draw backs:
1. Skeletons aren't totally unique. A skeleton may appear in both
the "dateFormats" and "availableFormats" objects, in which case
the same interval formats would be generated more than once.
2. Otherwise unique format patterns may only differ by the interval
patterns assigned to them. This would cause the UniqueStorage for
the format patterns to increase in size, impacting both compile
times and libunicode.so size.
|
|
See: https://unicode.org/reports/tr35/tr35-dates.html#dfst-day
|
|
This is an editorial change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/665871e
|
|
This is an editorial change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/513c05b
|
|
Persist EditingEngine mode in HackStudio and TextEditor when opening new
files or editing splits. Previously, the EditingEngine defaulted to a
RegularEditingEngine for a new Editor, even if Vim Emulation had been
selected in the existing Editor.
|
|
This will allow users of EditingEngine classes to determine current type
of EditingEngine (currently either vim or regular).
|
|
|
|
|
|
We now detect situations like this, where variables infinitely recur,
without crashing:
```css
div {
--a: var(--b);
--b: var(--a);
background: var(--a);
}
p {
--foo: var(--foo);
background: var(--foo);
}
```
|
|
We now stop processing variables once a length of 16384 tokens is
reached. This is an arbitrary number, but should be far beyond what
anyone will reasonably use, and small enough to not crash.
|
|
|
|
If a property is custom or contains a `var()` reference, it cannot be
parsed into a proper StyleValue immediately, so we store it as an
UnresolvedStyleValue until the property is compute. Then, at compute
time, we resolve them by expanding out any `var()` references, and
parsing the result.
The implementation here is very naive, and involves copying the
UnresolvedStyleValue's tree of StyleComponentValueRules while copying
the contents of any `var()`s it finds along the way. This is quite an
expensive operation to do every time that the style is computed.
|
|
This represents a property value that hasn't been converted to a
"proper" StyleValue yet. That is, it's either a custom property's value,
or a value that includes `var()` references, (or both!) since neither of
those can be fully resolved at parse time.
|
|
For our naive var() implementation, we need to be able to create
StyleBlockRules outside of the Parser, and these changes make that
possible.
|
|
|
|
|
|
This allows JS to keep an element alive by retaining a reference to
element.attributes
|
|
This allows document.implementation to keep the underlying document
alive for as long as we need it (for example, if someone holds on to a
DOMImplementation JS wrapper after the document is GC'd.)
|
|
This object already forwarded its ref count to DOM::Window. This patch
simply adopts the new RefCountForwarder base to achieve the same thing.
|
|
This is a convenience template that implements reference count
forwarding. This means that an object forwards ref() and unref() to
another object.
We can use this when two ref-counted objects need to keep each other
alive. This situation poses two problems:
- Using 2x RefPtr would cause a ref cycle and leak both objects.
- Using 2x WeakPtr would allow one of them to be destroyed early.
With RefCountForwarder, only one of the objects has a ref count. The
object with the ref count points to the forwarding object by using a
non-counting smart pointer (OwnPtr or NonnullOwnPtr). Thus, both objects
are kept alive by the same ref count, and they can safely point to each
other without worrying about disjoint lifetimes.
|
|
|
|
In the initial port of dos2unix, there was a miss in the validation
of the files. Let's switch to the original author's official
signed verification of the source :^)
|
|
Found while working on something else.
|
|
10140-1018E https://www.unicode.org/charts/PDF/U10140.pdf
|
|
11A00-11A47 https://www.unicode.org/charts/PDF/U11A00.pdf
|
|
|
|
Only two skipped tests remaining overall :^)
|
|
This is an editorial change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/271d71c
|
|
This is an editorial change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/7207a1c
|
|
This is an editorial change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/1f7e486
|
|
This is an editorial change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/516bf24
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
