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.
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.
[Android][0] and [Desktop][1] have already removed this field. This
follows suit.
The highlights:
- `SignalService.proto` removes some fields by making them `reserved`
- `ProtoWrappers.py` updates our code generation to support addresses
that only have a UUID (previously, you needed both a UUID and E164
field)
- Most everything else is removing E164s
[0]: 9c266e7995
[1]: 2b0d3cab40
Smartling exposes a simple REST API that’s fairly easy to adopt.
Some differences from the old approach:
- We get UTF-8 back instead of UTF-16, so there’s no need to use iconv.
- We don’t support “nb_NO”, so we don’t need to remove it each time we
fetch translations.
- We get back English fallbacks for .stringsdict files, so there’s no
need to merge them manually ourselves.
- We no longer support country-specific locales *and* the root language,
so we don’t need to merge, for example, “es” into “es-MX”.
- We handle language mapping & duplication inside the Swift script,
which will hopefully be more reliable than cp’ing directories.
_This change should have no user impact._ And you can see that the only
changes to generated files are in comments.
Before this change, we used comments to denote reserved or deprecated
fields. This works, but I think we should instead use the `reserved`
keyword, which offers a few advantages. From [the protobuf docs][0]:
> If you update a message type by entirely removing a field, or
> commenting it out, future users can reuse the field number when making
> their own updates to the type. This can cause severe issues if they
> later load old versions of the same .proto, including data corruption,
> privacy bugs, and so on. One way to make sure this doesn't happen is
> to specify that the field numbers (and/or names, which can also cause
> issues for JSON serialization) of your deleted fields are reserved.
> The protocol buffer compiler will complain if any future users try to
> use these field identifiers.
This updates our proto files to use `reserved` instead of comments. It
also adds support to our wrapper script. (I moved a few things around in
that script, too, for consistency.)
I think this is a useful change on its own, but I think it'll make
things a little better when we deprecate some fields, which we're
planning to do soon.
[0]: https://developers.google.com/protocol-buffers/docs/proto3#reserved
This should have no direct user impact.
We currently have two ways of sorting `#import` and `#include`
statements:
1. With our precommit script
2. With `clang-format` (via `git-clang-format`)
It *looks* like we aren't using `clang-format` (because of the
`SortIncludes: false` option in `.clang-format`) but we are,
which you can see by running `clang-format --dump-config`. As a separate
issue, it seems like we're not picking up the `clang-format`
configuration file (`clang-format --style=file:.clang-format
--dump-config` gives different results).
I've run into situations where the two of them "fight", so I think the
best thing to do is pick one. After some discussion, we decided to pick
`clang-format`.
This change should have no direct user impact.
This is just a file move.
I think this is a useful change on its own, but it may be useful in
upcoming changes too (e.g., making SignalServiceKit not a pod).
- Use “nb” instead of “no” for Norwegian
- Use “fr” for both “fr-FR” and “fr-CA”
Also: Remove redundant `tx pull` for App Store metadata. The next
request forces a fetch of all the supported languages, so the first
fetch isn’t necessary.
A couple of codegen scripts had an `--intermediates` flag. While I was
playing around with this (fixing something else), I noticed that these
flags don't work and cause a crash.
Instead of fixing those bugs, I thought it'd be better to just delete
this flag because I don't think anybody uses it.
Tested this by running `make` in the `sds_codegen/` directory, with
success.
Previously, sending a gift badge was not a durable operation, which
meant that crashes/failures could cause users to have their payment
methods charged without actually sending the badge.
Now, the flow is split up into two steps: non-durable parts before the
charge is attempted, and durable parts afterward.
The high-level flow is:
1. Prepare the payment, which involves a couple of repeatable network
requests.
2. Enqueue a job with the prepared payment, that:
1. Charges the payment method (idempotently)
2. Requests a receipt credential (idempotently)
3. Enqueues a gift message, and optionally a text message
3. When the job completes, open the conversation in the UI.
* 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
This respects the `giftBadges` capability when trying to send gift
badges. In other words, it prevents you from sending gift badges to
someone who lacks the capability.
The bulk of this change involves fetching and saving of this new
capability. The rest of the code involves showing it on the "choose
recipient" screen (and some debug screens).
The gist is:
```diff
-foo = foo + 1
+foo += 1
```
Most of the violations were in generated files, so I changed and re-ran the generator.
A few of these violations required implementing some new methods, which I added tests for.
See [the docs for this rule][0].
[0]: https://realm.github.io/SwiftLint/shorthand_operator.html
The `Emoji` enum had an [orphaned doc comment][0], which SwiftLint reported.
This updates that file's generator to fix the error. (SwiftLint is disabled for most of the file, though—a bit unfortunate, but probably correct for generated files.)
[0]: https://realm.github.io/SwiftLint/orphaned_doc_comment.html
This passes the `--pretty` flag to the symbolication script, which
slightly improves readability.
I also switched the flags to their long forms (`--output` instead of
`-o`, for example) because I feel that they're more readable. But that's
stylistic, and shouldn't affect the functionality of the script.
We added a symbolication script in
a55da92c2b. This commit makes a few small
changes:
- `subprocess.run` should be called with `check=True`
- Remove reference to `~/Symbols`, replace with reference to
`$SIGNAL_IOS_DSYMS` environment variable
- Rename an unused variable to `_`
- Open a file in binary mode (to avoid encoding issues)
We expose many of these builders to Objective-C, but Swift is unable
to map forward-declarations of those types (@class) back to the real
Swift classes because they're nested within the protos. Since we're
already using fully-qualified names even in Swift (e.g.
"SSKProtoContentBuilder"), nesting isn't worth the trouble it's
causing.
This change:
- Fixes some warnings reported by [Shellcheck][0]. Notably, if your repo
is in a folder with a space (e.g., `/Users/foo/My Code/Signal-iOS`),
this script wouldn't work.
- Adds `set -u` to error when using unbound variables, in case we make a
mistake
- Adds `set -o pipefail` to error if piping fails. Not used by this
script, but I put this line in all my shell script just in case
Tested this when taking 5.37.0 to production and it worked fine.
[0]: https://www.shellcheck.net/
_I recommend reviewing this with whitespace changes disabled._
Signal has renamed its primary branch to `main`. This updates references
to the old name, `master`, to either reference `main` or a specific
commit hash.
I also fixed a couple of small whitespace issues in a file I was
editing.
