This is adding in the new Windows 11 only version of taskbar pinning. For the new pinning to work, we need to use limited access feature tokens. Those are going to be made private and aren't included with this change.
This change will compile, and will work if built against the correct limited access feature tokens, as specified in developer local machine config files, but for every other build, the new taskbar pinning won't work and will fall back to the old methods.
I will implement the try / release building machines using the secret limited access feature tokens in a follow-up diff.
Differential Revision: https://phabricator.services.mozilla.com/D205004
The -ldl flag was previously set globally, it's now set for the libs
that use it.
Also rationalize the difference between HAVE_DLOPEN and HAVE_DLFCN_H.
Differential Revision: https://phabricator.services.mozilla.com/D203594
This is adding in the new Windows 11 only version of taskbar pinning. For the new pinning to work, we need to use limited access feature tokens. Those are going to be made private and aren't included with this change.
This change will compile, and will work if built against the correct limited access feature tokens, as specified in developer local machine config files, but for every other build, the new taskbar pinning won't work and will fall back to the old methods.
I will implement the try / release building machines using the secret limited access feature tokens in a follow-up diff.
Differential Revision: https://phabricator.services.mozilla.com/D205004
This is adding in the new Windows 11 only version of taskbar pinning. For the new pinning to work, we need to use limited access feature tokens. Those are going to be made private and aren't included with this change.
This change will compile, and will work if built against the correct limited access feature tokens, as specified in developer local machine config files, but for every other build, the new taskbar pinning won't work and will fall back to the old methods.
I will implement the try / release building machines using the secret limited access feature tokens in a follow-up diff.
Differential Revision: https://phabricator.services.mozilla.com/D205004
This is adding in the new Windows 11 only version of taskbar pinning. For the new pinning to work, we need to use limited access feature tokens. Those are going to be made private and aren't included with this change.
This change will compile, and will work if built against the correct limited access feature tokens, as specified in developer local machine config files, but for every other build, the new taskbar pinning won't work and will fall back to the old methods.
I will implement the try / release building machines using the secret limited access feature tokens in a follow-up diff.
Differential Revision: https://phabricator.services.mozilla.com/D205004
This is adding in the new Windows 11 only version of taskbar pinning. For the new pinning to work, we need to use limited access feature tokens. Those are going to be made private and aren't included with this change.
This change will compile, and will work if built against the correct limited access feature tokens, as specified in developer local machine config files, but for every other build, the new taskbar pinning won't work and will fall back to the old methods.
I will implement the try / release building machines using the secret limited access feature tokens in a follow-up diff.
Differential Revision: https://phabricator.services.mozilla.com/D205004
Now that -Wc++2a-compat is no longer enabled (bug 1887580), we don't need to -Wc++2a-compat warnings about u8"" string literals' type changing from const char[] in C++17 to const char8_t[] in C++20.
Depends on D206743
Differential Revision: https://phabricator.services.mozilla.com/D206744
This changes comes with several different refactorings all rolled into one,
unfotunately I couldn't find a way to pull them apart:
- First of all annotations now can either recorded (that is, we copy the value
and have the crash reporting code own the copy) or registered. Several
annotations are changed to use this functionality so that we don't need to
update them as their value change.
- The code in the exception handler is modified to read the annotations from
the mozannotation_client crate. This has the unfortunate side-effect that
we need three different bits of code to serialize them: one for annotations
read from a child process, one for reading annotations from the main process
outside of the exception handler and one for reading annotations from the
main process within the exception handler. As we move to fully
out-of-process crash reporting the last two methods will go away.
- The mozannotation_client crate now doesn't record annotation types anymore.
I realized as I was working on this that storing types at runtime has two
issues: the first one is that buggy code might change the type of an
annotation (that is record it under two different types at two different
moments), the second issue is that types might become corrupt during a
crash, so better enforce them at annotation-writing time. The end result is
that the mozannotation_* crates now only store byte buffers, track the
format the data is stored in (null-terminated string, fixed size buffer,
etc...) but not the type of data each annotation is supposed to contain.
- Which brings us to the next change: concrete types for annotations are now
enforced when they're written out. If an annotation doesn't match the
expected type it's skipped. Storing an annotation with the wrong type will
also trigger an assertion in debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D195248
The previous implementation used days since Jan 1 2000 for the last
16-bit segment. This was not unique enough and caused issues with
Antivirus software if two different channels were built on the same day.
The new approach uses hours since the last milestone bump and uses the
VCS to determine how long ago that was relative to the build time. This
means it will always reset when a new cycle begins, but still be unique
since the digits in the first 3 segments have incremented.
We also now use two of the 16-bits to encode the channel (nightly, beta,
ESR, and release). So two channels built within the same hour will still
be unique.
Using only 14-bits to store the 'hours since version bump', we have
about ~682 days from a version bump before we reach the maximum value we
can store. If a build is done after that point, the segment value will
always be the maximum value for that channel.
Differential Revision: https://phabricator.services.mozilla.com/D200989
Adding a new pref for a new SpiderMonkey feature or optimization requires a lot of boilerplate code.
This patch stack lets us eliminate almost all of this boilerplate by parsing `StaticPrefList.yaml`
at SpiderMonkey build time and generating code to automatically expose the `javascript.options.*`
prefs that have the `set_spidermonkey_pref` attribute.
Both JS shell and browser builds will default to the pref value in `StaticPrefList.yaml`.
In the JS shell, it'll be possible to set a pref value with `--setpref` or a custom shell flag.
Code for this will be added in later patches.
Differential Revision: https://phabricator.services.mozilla.com/D199992
