Skip to content

Conversation

@safaiyeh
Copy link
Owner

Summary

Changelog

[CATEGORY] [TYPE] - Message

Test Plan

@safaiyeh safaiyeh changed the title Update Folly Fix test_ios Jan 28, 2020
@safaiyeh safaiyeh closed this Jan 28, 2020
@safaiyeh safaiyeh reopened this Jan 28, 2020
@safaiyeh safaiyeh closed this Jan 28, 2020
@safaiyeh safaiyeh deleted the fix-test-ios branch January 28, 2020 03:40
@safaiyeh safaiyeh restored the fix-test-ios branch January 28, 2020 03:41
@safaiyeh safaiyeh deleted the fix-test-ios branch January 28, 2020 03:41
@safaiyeh safaiyeh restored the fix-test-ios branch January 28, 2020 03:41
@safaiyeh safaiyeh deleted the fix-test-ios branch January 28, 2020 03:53
safaiyeh pushed a commit that referenced this pull request Jul 17, 2020
Summary:
While in theory we should never delete views before removing them from the hierarchy, there are some exceptions:

(1) Some mysterious cases that don't seem like bugs, but where the child still seems to keep a reference to the parent:
(2) When deleting views as part of stopSurface.

On #1: in the past we had issues when we assumed that ViewManager.getChildCount() would return an accurate count. Sometimes it's just... wrong. Here, I've found at least one case where a View still has a parent after it's removed from the View hierarchy. I assume this is undocumented Android behavior or an Android bug, but either way, there's nothing I can do about it.

On #2: there are valid cases where we want to delete a View without explicitly removing it from the View hierarchy (it will eventually be removed from the hierarchy when the Root view is unmounted, but it may still be "in" a View hierarchy when it's deleted).

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D22321374

fbshipit-source-id: 9667bbe778c418f0216550638dc26ca48a58e5fa
safaiyeh pushed a commit that referenced this pull request Oct 26, 2020
Summary:
changelog: [internal]

Prevents 2 type converions:
1. int <-> size_t
2. int <-> int32_t

# Why is using size_t better when working with indexes.

## 1. Type conversion isn't for free.

Take this example

```
size_t calculate(int number) {
  return number + 1;
}
```

It generates following assembly (generated with armv8-a clang 10.0.0):

```
calculate(int):                          // calculate(int)
sub     sp, sp, facebook#16                     // =16
str     w0, [sp, facebook#12]
ldr     w8, [sp, facebook#12]
add     w9, w8, #1                      // =1
mov     w8, w9
sxtw    x0, w8
add     sp, sp, facebook#16                     // =16
ret
```

That's 9 instructions.

If we get rid of type conversion:

```
size_t calculate(size_t number) {
  return number + 1;
}
```

Assembly (generated with armv8-a clang 10.0.0):

```
calculate(unsigned long):                          // calculate(unsigned long)
sub     sp, sp, facebook#16             // =16
str     x0, [sp, facebook#8]
ldr     x8, [sp, facebook#8]
add     x0, x8, #1              // =1
add     sp, sp, facebook#16             // =16
ret
```

Compiler now produces only 7 instructions.

## Semantics

When using int for indexing, the type doesn't say much. By using `size_t`, just by looking at the type, it gives the reader more information about where it is coming from.

Reviewed By: JoshuaGross

Differential Revision: D24332248

fbshipit-source-id: 87ef982829ec14906ed9e002ea2e875fda4a0cd8
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants