Page MenuHomePhabricator
Differential D9697

[Flow202][lib][skip-ci] [5/23] Fix Flow issues with missing annotations on parameters in function declarations
ClosedPublic
Actions

Authored by ashoat on Nov 4 2023, 11:58 AM.
Tags
None
Referenced Files
F6162091: D9697.id33261.diff
Tue, Apr 22, 7:09 PM
Unknown Object (File)
Sat, Apr 19, 7:29 AM
Unknown Object (File)
Sat, Apr 19, 5:02 AM
Unknown Object (File)
Sat, Apr 19, 1:30 AM
Unknown Object (File)
Fri, Apr 18, 5:48 AM
Unknown Object (File)
Thu, Apr 17, 5:30 AM
Unknown Object (File)
Fri, Apr 4, 2:13 PM
Unknown Object (File)
Fri, Apr 4, 2:13 PM
View All Files
Subscribers
will

Details

Reviewers
tomek
Commits
rCOMM253f2a13b419: [Flow202][lib][skip-ci] [5/23] Fix Flow issues with missing annotations on…
Summary

The new version of Flow is showing a bunch of errors that look like this:

Error -------------------------------------------------------------------------- components/modal-overlay.react.js:35:51

An annotation on event is required because Flow cannot infer its type from local context. [missing-local-annot]

     32|     }
     33|   }, []);
     34|
     35|   const onBackgroundMouseDown = React.useCallback(event => {
     36|     firstClickRef.current = event.target;
     37|   }, []);
     38|

This diff adds the required annotations.

NOTE: CI will fail on this diff. I considered the possibility of fixing Flow errors BEFORE upgrading Flow, but it wasn't possible... in some cases, the fixes to support the new version of Flow caused errors in the old version. I could have hidden these type errors with $FlowFixMe lines and then later revert those, but that seemed like too much busy work.

Depends on D9696

Test Plan

Confirm the Flow errors go away

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

ashoat created this revision.Nov 4 2023, 11:58 AM
Herald added a subscriber: will. · View Herald TranscriptNov 4 2023, 11:58 AM
ashoat added a child revision: D9698: [Flow202][lib][skip-ci] [6/23] Fix Flow issues with computed properties.Nov 4 2023, 11:59 AM
Harbormaster returned this revision to the author for changes because remote builds failed.Nov 4 2023, 12:12 PM
Harbormaster failed remote builds in B23739: Diff 32701!
ashoat requested review of this revision.Nov 4 2023, 12:16 PM
tomek accepted this revision.Nov 6 2023, 4:39 AM
This revision is now accepted and ready to land.Nov 6 2023, 4:39 AM
ashoat updated this revision to Diff 32879.Nov 7 2023, 6:29 AM

Rebase

Harbormaster failed remote builds in B23858: Diff 32879!Nov 7 2023, 6:40 AM
ashoat mentioned this in D9771: [Flow202][web][skip-ci] [5/x] Address missing-local-annot type errors.Nov 8 2023, 11:33 AM
ashoat mentioned this in D9873: [Flow202][keyserver][skip-ci] [24/x] Address missing-local-annot type errors.Nov 13 2023, 3:26 PM
ashoat updated this revision to Diff 33261.Nov 15 2023, 6:47 AM

Rebase

Harbormaster failed remote builds in B24147: Diff 33261!Nov 15 2023, 6:59 AM
ashoat retitled this revision from [Flow202][lib] [5/23] Fix Flow issues with missing annotations on parameters in function declarations to [Flow202][lib][skip-ci] [5/23] Fix Flow issues with missing annotations on parameters in function declarations.Nov 19 2023, 11:46 AM
ashoat mentioned this in D10015: [Flow202][native][skip-ci] [31/x] Address missing-local-annot type errors.Nov 27 2023, 12:50 AM
This revision was landed with ongoing or failed builds.Nov 27 2023, 3:25 PM
Closed by commit rCOMM253f2a13b419: [Flow202][lib][skip-ci] [5/23] Fix Flow issues with missing annotations on… (authored by ashoat). · Explain Why
This revision was automatically updated to reflect the committed changes.
ashoat added a commit: rCOMM253f2a13b419: [Flow202][lib][skip-ci] [5/23] Fix Flow issues with missing annotations on….
ashoat mentioned this in rCOMM8cbe88a6c29d: [Flow202][web][skip-ci] [5/x] Address missing-local-annot type errors.
ashoat mentioned this in rCOMMcaa001751b16: [Flow202][keyserver][skip-ci] [24/x] Address missing-local-annot type errors.Nov 27 2023, 3:27 PM
ashoat mentioned this in rCOMMdb14a28e300e: [Flow202][native][skip-ci] [31/x] Address missing-local-annot type errors.

Revision Contents
Changeset List

Diff 33791

View Options

lib/components/modal-overlay.react.js

import ExpoModulesCore import ExpoModulesCore
import CryptoKit
public class AESCryptoModule: Module { public class AESCryptoModule: Module {
public func definition() -> ModuleDefinition { public func definition() -> ModuleDefinition {
Name("AESCrypto") Name("AESCrypto")
Function("hello") { () -> String in Function("generateKey", generateKey)
return "Hello world! 👋"
} }
} }
// MARK: - Function implementations
private func generateKey(destination: Uint8Array) throws {
let key = SymmetricKey(size: .bits256)
guard destination.byteLength * 8 == key.bitCount else {
throw InvalidKeyLengthException()
}
atulUnsubmitted
Not Done
Inline Actions

Before we even generate key via SymmetricKey, should we check that destination.byteLength is 32 and throw InvalidDestinationSizeException() if not?

It seems like destination is the input that we want to validate, so we should just do that directly? It's not really so much that SymmetricKey is giving us incorrect size key since it's (I'm assuming) always going to give us exactly the size we're asking for?

Feel free to re-request review if there's something I'm missing here.

atul: Before we even generate `key` via `SymmetricKey`, should we check that `destination.byteLength`…
bartekAuthorUnsubmitted
Done
Inline Actions

The only reason the guard is below SymmetricKey is that I wanted to use its bitCount property to get the desired destination length, but you're right that it can be done this way:

guard destination.byteLength == KEY_SIZE else {
  throw InvalidKeyLengthException()
}
let key = SymmetricKey(size: .bits256)

I'll refactor this as it is more clear solution

bartek: The only reason the guard is below `SymmetricKey` is that I wanted to use its `bitCount`…
key.withUnsafeBytes { bytes in
let _ = bytes.copyBytes(to: destination.rawBufferPtr())
}
}
// MARK: - Utilities
extension TypedArray {
func rawBufferPtr() -> UnsafeMutableRawBufferPointer {
UnsafeMutableRawBufferPointer(start: self.rawPointer,
count: self.byteLength)
}
}
// MARK: - Exception definitions
private class InvalidKeyLengthException: Exception {
override var reason: String {
"The AES key has invalid length"
}
} }
View Options

lib/components/modal-provider.react.js

import ExpoModulesCore import ExpoModulesCore
import CryptoKit
public class AESCryptoModule: Module { public class AESCryptoModule: Module {
public func definition() -> ModuleDefinition { public func definition() -> ModuleDefinition {
Name("AESCrypto") Name("AESCrypto")
Function("hello") { () -> String in Function("generateKey", generateKey)
return "Hello world! 👋"
} }
} }
// MARK: - Function implementations
private func generateKey(destination: Uint8Array) throws {
let key = SymmetricKey(size: .bits256)
guard destination.byteLength * 8 == key.bitCount else {
throw InvalidKeyLengthException()
}
atulUnsubmitted
Not Done
Inline Actions

Before we even generate key via SymmetricKey, should we check that destination.byteLength is 32 and throw InvalidDestinationSizeException() if not?

It seems like destination is the input that we want to validate, so we should just do that directly? It's not really so much that SymmetricKey is giving us incorrect size key since it's (I'm assuming) always going to give us exactly the size we're asking for?

Feel free to re-request review if there's something I'm missing here.

atul: Before we even generate `key` via `SymmetricKey`, should we check that `destination.byteLength`…
bartekAuthorUnsubmitted
Done
Inline Actions

The only reason the guard is below SymmetricKey is that I wanted to use its bitCount property to get the desired destination length, but you're right that it can be done this way:

guard destination.byteLength == KEY_SIZE else {
  throw InvalidKeyLengthException()
}
let key = SymmetricKey(size: .bits256)

I'll refactor this as it is more clear solution

bartek: The only reason the guard is below `SymmetricKey` is that I wanted to use its `bitCount`…
key.withUnsafeBytes { bytes in
let _ = bytes.copyBytes(to: destination.rawBufferPtr())
}
}
// MARK: - Utilities
extension TypedArray {
func rawBufferPtr() -> UnsafeMutableRawBufferPointer {
UnsafeMutableRawBufferPointer(start: self.rawPointer,
count: self.byteLength)
}
}
// MARK: - Exception definitions
private class InvalidKeyLengthException: Exception {
override var reason: String {
"The AES key has invalid length"
}
} }
View Options

lib/hooks/child-threads.js

import ExpoModulesCore import ExpoModulesCore
import CryptoKit
public class AESCryptoModule: Module { public class AESCryptoModule: Module {
public func definition() -> ModuleDefinition { public func definition() -> ModuleDefinition {
Name("AESCrypto") Name("AESCrypto")
Function("hello") { () -> String in Function("generateKey", generateKey)
return "Hello world! 👋"
} }
} }
// MARK: - Function implementations
private func generateKey(destination: Uint8Array) throws {
let key = SymmetricKey(size: .bits256)
guard destination.byteLength * 8 == key.bitCount else {
throw InvalidKeyLengthException()
}
atulUnsubmitted
Not Done
Inline Actions

Before we even generate key via SymmetricKey, should we check that destination.byteLength is 32 and throw InvalidDestinationSizeException() if not?

It seems like destination is the input that we want to validate, so we should just do that directly? It's not really so much that SymmetricKey is giving us incorrect size key since it's (I'm assuming) always going to give us exactly the size we're asking for?

Feel free to re-request review if there's something I'm missing here.

atul: Before we even generate `key` via `SymmetricKey`, should we check that `destination.byteLength`…
bartekAuthorUnsubmitted
Done
Inline Actions

The only reason the guard is below SymmetricKey is that I wanted to use its bitCount property to get the desired destination length, but you're right that it can be done this way:

guard destination.byteLength == KEY_SIZE else {
  throw InvalidKeyLengthException()
}
let key = SymmetricKey(size: .bits256)

I'll refactor this as it is more clear solution

bartek: The only reason the guard is below `SymmetricKey` is that I wanted to use its `bitCount`…
key.withUnsafeBytes { bytes in
let _ = bytes.copyBytes(to: destination.rawBufferPtr())
}
}
// MARK: - Utilities
extension TypedArray {
func rawBufferPtr() -> UnsafeMutableRawBufferPointer {
UnsafeMutableRawBufferPointer(start: self.rawPointer,
count: self.byteLength)
}
}
// MARK: - Exception definitions
private class InvalidKeyLengthException: Exception {
override var reason: String {
"The AES key has invalid length"
}
} }
View Options

lib/shared/state-sync/entries-state-sync-spec.js

import ExpoModulesCore import ExpoModulesCore
import CryptoKit
public class AESCryptoModule: Module { public class AESCryptoModule: Module {
public func definition() -> ModuleDefinition { public func definition() -> ModuleDefinition {
Name("AESCrypto") Name("AESCrypto")
Function("hello") { () -> String in Function("generateKey", generateKey)
return "Hello world! 👋"
} }
} }
// MARK: - Function implementations
private func generateKey(destination: Uint8Array) throws {
let key = SymmetricKey(size: .bits256)
guard destination.byteLength * 8 == key.bitCount else {
throw InvalidKeyLengthException()
}
atulUnsubmitted
Not Done
Inline Actions

Before we even generate key via SymmetricKey, should we check that destination.byteLength is 32 and throw InvalidDestinationSizeException() if not?

It seems like destination is the input that we want to validate, so we should just do that directly? It's not really so much that SymmetricKey is giving us incorrect size key since it's (I'm assuming) always going to give us exactly the size we're asking for?

Feel free to re-request review if there's something I'm missing here.

atul: Before we even generate `key` via `SymmetricKey`, should we check that `destination.byteLength`…
bartekAuthorUnsubmitted
Done
Inline Actions

The only reason the guard is below SymmetricKey is that I wanted to use its bitCount property to get the desired destination length, but you're right that it can be done this way:

guard destination.byteLength == KEY_SIZE else {
  throw InvalidKeyLengthException()
}
let key = SymmetricKey(size: .bits256)

I'll refactor this as it is more clear solution

bartek: The only reason the guard is below `SymmetricKey` is that I wanted to use its `bitCount`…
key.withUnsafeBytes { bytes in
let _ = bytes.copyBytes(to: destination.rawBufferPtr())
}
}
// MARK: - Utilities
extension TypedArray {
func rawBufferPtr() -> UnsafeMutableRawBufferPointer {
UnsafeMutableRawBufferPointer(start: self.rawPointer,
count: self.byteLength)
}
}
// MARK: - Exception definitions
private class InvalidKeyLengthException: Exception {
override var reason: String {
"The AES key has invalid length"
}
} }
View Options

lib/shared/state-sync/threads-state-sync-spec.js

Loading...
View Options

lib/shared/state-sync/users-state-sync-spec.js

Loading...