This change may improve performance slightly but should have no other
user impact.
`myString.isEmpty` is faster than `myString.count == 0` or equivalent,
because computing `count` may require iterating over the string.
I tried to fix all occurrences of this.
Tested this by sending a message in a group and doing a full
re-registration, just in case I broke something there.
Change license to AGPL
This commit:
- Updates the `LICENSE` file
- Start every file with something like:
// Copyright YEAR_FIRST_PUBLISHED Signal Messenger, LLC
// SPDX-License-Identifier: AGPL-3.0-only
---
First, I removed existing license headers with this Ruby 3.1.2 script:
require 'set'
EXTENSIONS_TO_CHECK = Set['.h', '.hpp', '.cpp', '.m', '.mm', '.pch', '.swift']
same = 0
different = 0
all_files = `git ls-files`.lines.map { |line| line.strip }
all_files.each do |relative_path|
if relative_path == 'Pods'
next
end
unless EXTENSIONS_TO_CHECK.include? File.extname(relative_path)
next
end
path = File.expand_path(relative_path)
contents = File.read(path)
new_contents = contents.sub(/\/\/\n\/\/ Copyright .*\n\/\/\n\n/, '')
if contents == new_contents
same += 1
else
different += 1
end
File.write(path, new_contents)
end
puts "updated #{different} file(s), left #{same} untouched"
I'm sure this script could be improved, but it worked well enough.
Then, I created `Scripts/lint/lint-license-headers` and ran it to auto-
fix a lot of files. This changed the mode of some files, but I think
that's actually desirable. For example,
`SignalServiceKit/src/Util/AppContext.m` previously had a mode of
`0755/-rwxr-xr-x`, and it's now `0644/-rw-r--r--`.
Then I fixed some stragglers and updated the precommit script.
See [a similar change in the Desktop app][0].
[0]: 8bfaf598af
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.
The non-lazy map and filter always make a new array or dictionary,
which is often consumed immediately into a Set. Using `lazy` avoids
that intermediate allocation, as well as the need to loop over the
array or dictionary a second time.
This is a micro-optimization, but several of these accessors are
accessed fairly frequently, so we might as well make them faster.
Currently, group (v2) updates are just instances of `TSOutgoingMessage`.
This works, but is inconsistent with other outgoing messages, which
subclass it.
This refactor changes that to make things consistent.
I think this is a useful change on its own, but it will also make future
changes easier.
This change should have no user impact.
We effectively had code like this:
#if TESTABLE_BUILD
foo()
#if TESTABLE_BUILD
bar()
#endif
#endif
The inner ones are unnecessary, so I removed them.
Group snapshots fetched from the service do not store the
`didJoinFromInviteLink` field on their members, and when we parse a
snapshot into a group model we hardcode this value to `false` for all
members. However, we store that field locally on a `GroupMembership`'s
`MemberStateMap` when processing an "add members" change action, as the
field is provided in the `AddMember` change action proto.
This becomes an issue, since when we refresh the group's state from the
service (which we do periodically, e.g. when opening a group for the
first time after launch) the `GroupMembership` from the group's snapshot
on the service will not match the `GroupMembership` we have locally,
even though they are from the same revision, due to mismatched
`didJoinFromInviteLink` values (hardcoded in the snapshot).
Consequently, we believed we were "updating the group model in a user-
facing way", but the only change therein was clobbering a
`didJoinFromInviteLink: true` to `...: false`, which was 1) wrong and
2) did not have a description to show.
This commit changes `GroupMembership` to ignore values for
`didJoinFromInviteLink` when comparing equality. This means that when we
parse a snapshot into a `TSGroupModel` with all those values hardcoded
to false, but otherwise identical to our local, we will no longer see it
as different from our local (and subsequently clobber our local and
generate an empty update).
_I recommend reviewing this with whitespace changes disabled._
`RemoteConfig.groupsV2InviteLinks` has been fully enabled for awhile
now. This removes it, and everything that depended on it. Even let us
remove a couple of strings!
* Little fix for context menu
* Add 'My Stories' section to stories tab
* Add new story thread types
* Show stories in conversation picker
* Support for sending stories
* Update story list when sending stories
* Add basic 'My Stories' view controller
* Initial stories settings screens
* Consolidate TSPrivateStoryThread and TSMyStoryThread into one class
* Require an explicit read transaction to initialize an outgoing message
* Fix linting
* Allow enabling group story from internal settings
* Fix tests
* PR Feedback
A migration (introduced in b2c0e975b6)
tries to save legacy avatars to disk. However, if that legacy avatar
data is invalid, we'd crash on launch.
A user encountered this.
Our possible solutions:
1. If legacy avatar data is invalid, just drop it.
2. If legacy avatar data is invalid, try to repair it. (For example, if
it's too large, try to resize it.) This might not fix the user's
issue—unfortunately, we don't know why the avatar was invalid.
3. Loosen our definition of a valid avatar. (For example, increase the
maximum size.) This also might not fix things—we don't know how the
avatar was invalid.
I went with the first solution.
This was difficult to test. While developing, I made a temporary button
that (1) updated a group, giving it an empty legacy avatar buffer (2)
tried to migrate it.
(Thanks to c5bd634ff1 for making this easy
to diagnose!)
_I recommend reviewing this with whitespace changes disabled._
This fixes violations of [SwiftLint's `implicit_getter` rule][0] by
removing explicit getters when an implicit one would do.
[0]: https://realm.github.io/SwiftLint/implicit_getter.html
There are some Swift-only features that are part of these protocols, so
they were split into Obj-C and Swift variants. However, the class itself
only reports conformance to the Swift variant, which leads to warnings
when using the class in Objective-C.
Commit 451fa08c22
had some bugs and was reverted by commit
12883e5db5.
This commit brings it back along with fixes.
Specific bug fixes:
* Verification status for a group was inverted.
* The local address should not be considered for
deciding if a group is verified.
