Summary: This change applies all Arcanist recommended lint changes, which amounts to changing copyright headers and some cases of whitespace changes.
Reviewed By: yungsters
Differential Revision: D40060899
fbshipit-source-id: b62f9472e6ef58a3fc3d22eed661578a2635cb1f
Summary:
Using compiler flag -fvisibility=hidden and explicitly setting visibility to default to public methods
#Changelog:
[Internal] [Yoga] Use compiler flag -fvisibility=hidden for reducing yoga binary size
Reviewed By: astreet
Differential Revision: D18029030
fbshipit-source-id: 545e73f9c25f3108fc9d9bb7f08c157dbc8da005
Summary:
`/*` is the standard throughout open source code. For example, Firefox uses single /*: https://hg.mozilla.org/mozilla-central/file/21d22b2f541258d3d1cf96c7ba5ad73e96e616b5/gfx/ipc/CompositorWidgetVsyncObserver.cpp#l3
In addition, Rust considers `/**` to be a doc comment (similar to Javadoc) and having such a comment at the beginning of the file causes `rustc` to barf.
Note that some JavaScript tooling requires `/**`. This is OK since JavaScript files were not covered by the linter in the first place, but it would be good to have that tooling fixed too.
Reviewed By: zertosh
Differential Revision: D15640366
fbshipit-source-id: b4ed4599071516364d6109720750d6a43304c089
Summary:
Adds a data structure that holds a series of values that can be *borrowed* for exclusive writing.
That means, that only a single consumer can write to any value owned by the data structure.
In addition, the data structure exposes read access via iteration over all contained values.
A typical use case would be a counter with thread-local values that are accumulated by readers in other parts of a programm. The design carefully avoids the use of atomics or locks for reading and writing. This approach avoids cache flushes and bus sync between cores.
Borrowing and returning a value go through a central lock to guarantee the consistency of the underlying data structure.
Values are allocated in a `std::forward_list`, which typically should avoid two values in the same cache line -- in that case, writing to one value would still cause cache flushing on other cores. An alternative approach would be to allocate values continuously on cache line boundaries (with padding between them). We can still change the code if the current approach turns out to be too naive (non-deterministic).
Reviewed By: SidharthGuglani
Differential Revision: D15535018
fbshipit-source-id: 212ac88bba9682a4c9d4326b46de0ee2fb5d9a7e
