This time, existing config.status trying to import it will throw an exception
that will trigger a re-configure.
Differential Revision: https://phabricator.services.mozilla.com/D43215
--HG--
extra : moz-landing-system : lando
As seen in bug 1575774/1575959, things can go badly when config.status
doesn't match expectations, especially when most mach commands try to
read it, starting with mach clobber, which is supposed to be the one
commant to get away from most problems.
The idea here is to throw a recognizable exception so that callers can
react accordingly. While not obvious from the patch, the result is that
running e.g. mach build with a broken config.status will automatically
run configure (because the relevant caller actually handles the rethrown
exception that way).
There are other calls to from_config_status in the mozbuild reader, but
that can't be reached before MozbuildObject.config_environment.
Differential Revision: https://phabricator.services.mozilla.com/D43214
--HG--
extra : moz-landing-system : lando
The method name is really unclear what's done. The method does 3 things.
One is try to select a `<br>` element in empty block if given range is
collapsed in the block. This is moved as
`HTMLEditor::SelectBRElementIfCollapsedInEmptyBlock()`. Next, it extends the
given range to include adjuscent whitespaces only when edit sub-action is
inserting or deleting text. This is moved as
`HTMLEditor::CreateRangeIncludingAdjuscentWhiteSpaces()`. Finally, when
handling the other edit sub-actions, extends the given range to start/end
of line at both edges. This is moved as
`HTMLEditor::CreateRangeExtendedToHardLineStartAndEnd()`.
And also this patch makes each caller of `PromoteRange()` to check edit
sub-action by themselves. Unfortunately, this duplicates same logic to
multiple places, but makes what they do clearer. I think that the duplication
issue should be fixed later if necessary. Instead, we should shine the
blackbox of `HTMLEditRules` right now.
Differential Revision: https://phabricator.services.mozilla.com/D43017
--HG--
extra : moz-landing-system : lando
2019-08-23 Kevin Jacobs <kjacobs@mozilla.com>
* tests/common/cleanup.sh:
Bug 1560593 - Check that BUILD_OPT is defined before testing its
value. r=jcj
[44aa330de2aa] [NSS_3_46_BETA1]
* cmd/strsclnt/strsclnt.c:
Bug 1575968 - Add strsclnt option to enforce the use of either IPv4
or IPv6 r=jcj
[da284d8993ea]
2019-08-23 Marcus Burghardt <mburghardt@mozilla.com>
* gtests/softoken_gtest/softoken_gtest.cc:
Bug 1573942 - Gtest for pkcs11.txt with different breaking line
formats. r=kjacobs
[d07a07eb0e40]
2019-08-21 Kevin Jacobs <kjacobs@mozilla.com>
* lib/util/utilmod.c:
Bug 1564284: Added check for CR + LF, r=marcusburghardt,kjacobs
Looks good and it was already tested locally with this gtest patch:
[d1d2e1e320cd]
2019-08-22 Martin Thomson <mt@lowentropy.net>
* lib/ssl/ssl3con.c:
Bug 1528666 - Formatting, a=bustage
[60eeac76c8ec]
2019-08-20 Martin Thomson <martin.thomson@gmail.com>
* gtests/ssl_gtest/ssl_0rtt_unittest.cc,
gtests/ssl_gtest/ssl_resumption_unittest.cc, lib/ssl/ssl3con.c:
Bug 1528666 - Correct resumption validation checks, r=jcj
We allowed cross-suite resumption before, but it didn't work. This
enables that for clients.
As a secondary minor tweak, clients will no longer validate the
availability of a cipher suite based on their configured version
range when attempting resumption. Instead, they will check whether
the suite works for the version in the session that they are
attempting to resume. In theory, this doesn't change anything
because the previous session should not have selected an
incompatible combination of version and cipher suite, but it's worth
being extra precise.
[cab2c8905214]
2019-08-22 Martin Thomson <mt@lowentropy.net>
* gtests/ssl_gtest/ssl_auth_unittest.cc,
gtests/ssl_gtest/ssl_resumption_unittest.cc, lib/ssl/ssl3con.c:
Bug 1568803 - More tests for client certificate authentication,
r=kjacobs
These were previously disabled because of difficulties (at the time)
in writing these tests for TLS 1.3. The framework, and my
understanding of it, has since improved, so these tests can be
restored and expanded. This exposed a minor correctness issue that
is also corrected.
[95f97d31c313]
Differential Revision: https://phabricator.services.mozilla.com/D43308
--HG--
extra : moz-landing-system : lando
`HTMLEditRules::GetPromotedPoint()` does too many things. Therefore, this patch
splits it to 3 methods. One is for specific `EditSubAction` values, that's
the first block in `GetPromotedPoint()`. It's named as
`GetWhiteSpaceEndPoint()`. Next one is for expanding start of the range to
start of its line. It's named as `GetCurrentHardLineStartPoint()`. The last
one is for expanding end of the range to end of its line. It's named as
`GetCurrentHardLineEndPoint()`.
Differential Revision: https://phabricator.services.mozilla.com/D42791
--HG--
extra : moz-landing-system : lando
This patch gets rid of gUsages in LSNG. This provides better consistency and
makes it easier to cache quota info on disk.
The patch also fixes some edge cases when usage was not adjusted correctly after
a failed file or database operation.
Differential Revision: https://phabricator.services.mozilla.com/D38229
--HG--
extra : moz-landing-system : lando
The alert_on values from the test INI were not being passed into the test settings json via manifest.py, this patch will fix this.
Differential Revision: https://phabricator.services.mozilla.com/D43049
--HG--
extra : moz-landing-system : lando
The fix here is to first check `NS_FAILED(rv)`, because if that's the
case, `cancel` wasn't necessarily set to a value.
As best practice I initialized `cancel` and `handled` with default
values.
Differential Revision: https://phabricator.services.mozilla.com/D43071
--HG--
extra : moz-landing-system : lando
Some of it was dead code, another was inlining a not very useful function (and
in one case redundant, since EnsureInitialized() happened right after
Refresh()).
Differential Revision: https://phabricator.services.mozilla.com/D43042
--HG--
extra : moz-landing-system : lando
Older config.status laying around in old trees are read by mach whenever
it runs, including when running mach clobber. Those files still try to
include mozbuild.util.encode, which is not here anymore. So we restore
the function for now to unbreak those.
Differential Revision: https://phabricator.services.mozilla.com//D43132
--HG--
extra : histedit_source : 3eb10cc8e18cc9094887061b00705afb6e705b54
Based on discussions with :djvj, it seems that this IC attachment logic is
overly conservative. We're seeing a case where the `__proto__` of a constructor
function is reassigned, which causes all instanceof ICs to fail to attach. The
test case is like:
function C() { /* ... */ }
C.__proto__ = D;
var o = new C();
var result = o instanceof C; // this IC fails to attach
This change generalizes the IC attachment logic to check whether @@hasInstance
is defined anywhere below Function in the prototype chain of the RHS. If not,
it is still safe to attach the IC; the IC simply needs to guard on the
prototype chain to ensure no @@hasInstance override is inserted later.
Differential Revision: https://phabricator.services.mozilla.com/D42366
Bug 1575135 changed check_cmd_output to return unicode strings, but a
couple places were already trying to do their own decoding, which now
can fail. Remove those.
Interesting the decoding was previously broken on Windows, this
actually fixes it (the output of hg config is not actually utf-8 on
Windows).
Differential Revision: https://phabricator.services.mozilla.com/D43044
--HG--
extra : moz-landing-system : lando
Most live nursery strings can be deduplicated in moveToTenured through a hashset.
Dependent strings are complicated to deal with since their chars need to be updated with the newly deduplicated base chars.
If the dependent string is tenured, its bases cannot be deduplicated since a tenured dependent string chars cannot be updated. Otherwise, the following steps will be able to update its chars.
1. Preserve the nursery base chain by saving dependent string nursery bases in its relocation overlay. This allows dependent string nursery root base to be reached.
2. Calculate the original dependent string base offset: dependent string nursery chars - dependent string root base nursery chars. Root base nursery chars is saved in its relocation overlay.
3. Update the dependent string chars with its new root base chars and the calculated offset.
4. Assign either the root base or the undepended string in which the dependent string uses chars from as the new base to unchain any potentially long dependency chain.
Differential Revision: https://phabricator.services.mozilla.com/D39440
--HG--
extra : moz-landing-system : lando
