The only place we call this in production code ensures that all members
already support gv2. As a result, there’s no reason to try and enable
gv2 -- it’s already enabled by the time we reach this code.
There are a few places in the Debug UI that may be relying on these CDS
lookups. I’ve removed one of them since there are existing “clone as v1”
and “clone as v2” options that do nearly the same thing. In another
case, I’ve dropped a reference to a live, non-test account. The other
places in the Debug UI that use this method either construct invalid
phone numbers that will never pass a CDS lookup, or they explicitly
provide UUIDs, which would exclude them from performing a lookup.
This fixes our remaining SwiftLint violations, which were small.
It also updates the precommit script to fail if any violations are
found, even warnings. This will cause CI to fail if you include a file
that isn't SwiftLint-compatible.
If a user's database is corrupted, we now try to fix it. I recommend
reviewing `DatabaseRecovery` to see how this works, and
`DatabaseRecoveryViewController` for the bulk of the UI.
* sort system stories normally after viewing
* scroll to hidden stories after hiding (or unhiding). Scroll to hidden story section after expanding
* if hiding/unhiding/deleting a story from within a viewer, proceed to the next story or context and remove the previous one from the viewer
This restores the behavior prior to
4a0141be41, where I made a mistake that
affect development builds.
Previously, the generated code looked like this, to prevent
instantiation of `SignalServiceAddress`es with no identifiers:
// This is a sketch!
let address: SignalServiceAddress? = {
guard hasUuid || hasE164 else { return nil }
let address = SignalServiceAddress(uuid: uuid, e164: e164)
guard address.isValid else {
owsFailDebug("address was unexpectedly invalid")
return nil
}
return address
}()
It makes sense (to me) to do this, because all proto fields are
optional. That means you can have a valid message that lacks both of
these fields, which is allowed. It shouldn't error.
However, I changed it to the equivalent of this, which caused an error
in `SignalServiceAddress`'s initializer:
let address: SignalServiceAddress? = {
let address = SignalServiceAddress(uuid: uuid, e164: e164)
guard address.isValid else {
return nil
}
return address
}()
This reverts that to avoid the debug assertion failure. I don't think
this ever affected "real" builds beyond some extra logging.
_This change should have no user impact._
This cleans up the way we generate registration IDs. It:
- Rewrites the generation code in Swift
- Removes the "sneaky transaction" method. I did this for clarity, and
because we won't use it for much longer
- Turns a log warning into a regular log—generating a registration ID is
not a problem
- Adds tests
I think this is a useful change on its own, but will be handy for an
upcoming change, too.
Previously, we collected all URL matches and then searched through them.
Now, we search lazily, which should improve performance.
I added a perf test that repeats a URL a million times. The new code
finishes in ~0.001 seconds on my machine. The old code does not finish.
