Bug 729519 [1] made the empty frame list be allocated in the
`.rodata` (read-only) section. However, the setup can be simplified.
To verify that `sEmptyList` is still allocated in the `.rodata` section, I used
the following steps on my local Linux build:
1. Move `nsFrameList.cpp` in moz.build from UNIFIED_SOURCES to SOURCES.
2. Run `./mach build`.
3. Run `objdump -x $(OBJDIR)/layout/generic/nsFrameList.o | grep sEmptyList`.
4. Verify that the output `sEmptyList` has `.rodata`. The objdump output looks
like this:
```
0000000000000038 g O .rodata 0000000000000010 .hidden _ZN11nsFrameList10sEmptyListE
```
[1] Specifically, this commit:
https://hg.mozilla.org/mozilla-central/rev/c320c5821f98
Differential Revision: https://phabricator.services.mozilla.com/D214226
With only the Part 1, `layout/generic/crashtests/1683126.html` will timeout.
It can be reproduced locally via
```
./mach crashtest layout/generic/crashtests/1683126.html
```
It is because if we destroy a frame list from the first child to the last child,
each time we destroy the first child [1], the second child become the new first
child, and we have to update the first-in-flow and first-continuation cache for
later continuations, which is a linear time operation.
[1] See nsSplittableFrame::RemoveFromFlow() with the argument being the first
child in a frame list.
Differential Revision: https://phabricator.services.mozilla.com/D197967
With only the Part 1, `layout/generic/crashtests/1683126.html` will timeout.
It can be reproduced locally via
```
./mach crashtest layout/generic/crashtests/1683126.html
```
It is because if we destroy a frame list from the first child to the last child,
each time we destroy the first child [1], the second child become the new first
child, and we have to update the first-in-flow and first-continuation cache for
later continuations, which is a linear time operation.
[1] See nsSplittableFrame::RemoveFromFlow() with the argument being the first
child in a frame list.
Differential Revision: https://phabricator.services.mozilla.com/D197967
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
After moving FrameChildListID into mozilla namespace, `kPrincipalList` etc. are
also exposed in the mozilla namespace. In the next part, I'll convert
FrameChildListID enum into an enum class, so the naming pollution shouldn't be
an issue.
This patch has a nice side effect that it is now easier to remove all the
aliases of FrameChildListID (`kPrincipalList` etc.) defined in multiple places
since it is confusion to have the same thing written in different ways, e.g.
`nsIFrame::kPrincipalList`, `mozilla::layout::kPrincipalList`,
`FrameChildListID::kPrincipalList`, `kPrincipalList`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D161863
After moving FrameChildListID into mozilla namespace, `kPrincipalList` etc. are
also exposed in the mozilla namespace. In the next part, I'll convert
FrameChildListID enum into an enum class, so the naming pollution shouldn't be
an issue.
This patch has a nice side effect that it is now easier to remove all the
aliases of FrameChildListID (`kPrincipalList` etc.) defined in multiple places
since it is confusion to have the same thing written in different ways, e.g.
`nsIFrame::kPrincipalList`, `mozilla::layout::kPrincipalList`,
`FrameChildListID::kPrincipalList`, `kPrincipalList`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D161863
The removed SetFrames() is slow (it traverses the next sibling chain to find the
last sibling) and has only one caller. Let's remove it.
The rewrite in nsInlineFrame::PullOneFrame() doesn't change behavior because
`frame` is just removed from the overflow list, so it won't have any next
sibling. We are creating a frame list containing only `frame`.
Differential Revision: https://phabricator.services.mozilla.com/D160839
RemoveFramesAfter and ExtractTail have similar purpose, so we really should keep
one of them to avoid confusion.
They have the following minor differences:
1. RemoveFramesAfter() keeps aFrame in the list, while ExtractTail() returns it.
2. If aFrame is empty, RemoveFramesAfter() returns the entire list, while
ExtractTail returns an empty list.
It's more convenient for the existing callers to use the RemoveFramesAfter(), so
ExtractTail is unneeded.
After this patch, both RemoveFramesAfter() and RemoveFramesBefore() return the
entire list if aFrame is nullptr.
Rename RemoveFramesAfter() to TakeFramesAfter() for symmetry with
TakeFramesBefore().
This change shouldn't change the behavior.
Differential Revision: https://phabricator.services.mozilla.com/D158807
I feel it's hard to understand the purpose of ExtractHead(), especially where
aFrame is going after the call. Therefore, I rename it to TakeFramesBefore(),
and have it complement the existing RemoveFramesAfter(), which will be rename
later. No behavioral change intended.
Also, slightly reword the method's documentation to reflect the its new
name. (Remove the "sibling" wording from the comment since it's an
implementation details that frames are actually a doubly linked list.)
Differential Revision: https://phabricator.services.mozilla.com/D158806
This is a preparation to remove nsFrameList::FrameLinkEnumerator in the next
part.
FrameLinkEnumerator::Find() can be replaced with std::find/std::find_if.
Differential Revision: https://phabricator.services.mozilla.com/D158700
AutoFrameListPtr might be used more frequently after we add more APIs to
handle overflow container list and excess overflow container list in
bug 1641085.
The improvements in this patch includes:
* Mark AutoFrameListPtr as MOZ_RAII and final class.
* Move AutoFrameListPtr into mozilla namespace since we don't use layout
sub-namespace that much these days.
* Remove the AutoFrameListPtr type alias in nsGridContainerFrame's
header since it's not used.
Differential Revision: https://phabricator.services.mozilla.com/D77568
This patch changes remaining things under `layout/`. However, there are some
places which still need to use `nsIPresShell`. That will be fixed in a
follow up bug.
Differential Revision: https://phabricator.services.mozilla.com/D27477
`nsPresContext` should use `mozilla::PresShell` directly instead of
`nsIPresShell`. This patch makes it.
Unfortunately, `nsPresContext` and `nsIFrame` have `PresShell()`. Therefore,
we cannot use `PresShell*` in its methods so that this patch uses `mozilla::`
namespace prefix.
It might be better to rename them as `PresShellPtr()` in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D25721
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
Structs in our style system use an arena-style allocation system,
managed by the presshell to which they belong. All of the relevant
overloads that forward allocation requests to the presshell declare
themselves as CPP_THROW_NEW, which indicates that they do not throw
exceptions. The C++ specification states that operator new overloads
that declare themselves to not throw exceptions require a null check on
their return value. However, the relevant presshell allocation method,
AllocateByObjectID, is infallible and will never return a null pointer.
The callers of all of these methods are therefore doing useless
(compiler-generated) null checks. Let's get rid of those useless checks
by removing the CPP_THROW_NEW annotations. This change declares these
methods will return non-null pointers and throw exceptions in case of
errors--but as we don't use exceptions, and AllocateByObjectID will
abort on OOM, everything works out OK.
Structs in our style system use an arena-style allocation system,
managed by the presshell to which they belong. All of the relevant
overloads that forward allocation requests to the presshell declare
themselves as CPP_THROW_NEW, which indicates that they do not throw
exceptions. The C++ specification states that operator new overloads
that declare themselves to not throw exceptions require a null check on
their return value. However, the relevant presshell allocation method,
AllocateByObjectID, is infallible and will never return a null pointer.
The callers of all of these methods are therefore doing useless
(compiler-generated) null checks. Let's get rid of those useless checks
by removing the CPP_THROW_NEW annotations. This change declares these
methods will return non-null pointers and throw exceptions in case of
errors--but as we don't use exceptions, and AllocateByObjectID will
abort on OOM, everything works out OK.
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
Ting-Yu Lin