Android: Added syscall support

[YohDeadfall]

According to the issue's description I moved the whole syscall implementation into a separate file, so it's a little bit more than just "thread APIs". Anyway, all of these system calls are available on Android.

Closes #3618.

[RalfJung]

Please don't rebase when there isn't a conflict. Github is terrible at dealing with force pushes so rebasing makes re-reviewing a lot harder.

[RalfJung]

Looks good, thanks!

Please squash the commits (with git rebase --keep-base).

[RalfJung]

@rustbot author

[YohDeadfall]

Please don't rebase when there isn't a conflict. Github is terrible at dealing with force pushes so rebasing makes re-reviewing a lot harder.

There were no conflicts at all, but for whatever reason the repository required to update the branch (can be set in the settings). This was blocking the merge ability.

Right now I see the same button, but all the checks are green and the update isn't mandatory.

[YohDeadfall]

This was blocking the merge ability.

Seeing that once again, it seems that there's just an UI issue. While some checks are running, the message "This branch is out-of-date with the base branch" has a gray icon like it's mandatory while it isn't.

[YohDeadfall]

@rustbot review

[RalfJung]

There were no conflicts at all, but for whatever reason the repository required to update the branch (can be set in the settings). This was blocking the merge ability.

No it doesn't block the merge, you can just ignore that message.

[RalfJung]

That force-push has a diff, so when you squashed you didn't use --keep-base... I was asking you to use that flag for a reason, it makes reviewing a lot easier. Please follow the instructions we give, they are there for a reason. (Mostly the reason is github being not great at dealing with some aspects of git, which means a lot of people need to spend a lot of time working around the deficiencies of the tool we are using.)

[RalfJung]

Actually that force push diff is really strange, it goes in the wrong direction?!? What on Earth is github doing here...

[RalfJung]

Or did you un-do your earlier rebase? That's not helpful, it just leads to even more diffs github can't deal with...

[RalfJung]

Anyway diff still looks good, thanks for the PR!

[YohDeadfall]

Or did you un-do your earlier rebase? That's not helpful, it just leads to even more diffs github can't deal with...

Shouldn't be since I used --keep-base.

No it doesn't block the merge, you can just ignore that message.

Yeah, but the UI is the same as if it's mandatory. There's no way to distinguish these two cases while checks are running. That led me to thing that I had to update the branch first. It's only possible when it's finished, so the check mark is green even if there's the message.

[YohDeadfall]

Buy the way, I see that this time you didn't use bors but instead the built-in merge queue. Is the Rust project switching them, or is it just that repo?

[RalfJung]

Buy the way, I see that this time you didn't use bors but instead the built-in merge queue. Is the Rust project switching them, or is it just that repo?

The main Rust repo won't switch, but most of the rest is slowly switching.

Shouldn't be since I used --keep-base.

Very strange... but I think somehow your branch did get un-rebased. Maybe you did the rebase with the button in the github UI but didn't pull that change so when you did the squash locally and force-pushed that it undid what you did in the UI?

Yeah, but the UI is the same as if it's mandatory. There's no way to distinguish these two cases while checks are running. That led me to thing that I had to update the branch first. It's only possible when it's finished, so the check mark is green even if there's the message.

When there is an actual conflict github shows a list of files that have conflicts. It doesn't even start CI in that case. So that should be enough to distinguish the two cases.

[YohDeadfall]

Very strange... but I think somehow your branch did get un-rebased. Maybe you did the rebase with the button in the github UI but didn't pull that change so when you did the squash locally and force-pushed that it undid what you did in the UI?

Indeed, just rechecked the bash history and found that I did:

git fetch origin
git reset --hard android-syscall

Note that no remote was provided, so technically it's noop. The local branch wasn't updated. Sorry for inconvenience (:

When there is an actual conflict github shows a list of files that have conflicts. It doesn't even start CI in that case. So that should be enough to distinguish the two cases.

Unfortunately not so helpful, I wrote #3998 (comment) where explained the situation. Some repositories require updates even if there are no conflicts. But if the CI isn't triggered on mandatory updates, then it might be fine. Still it requires awareness about all GH behaviors which are easy to forget or simply don't know (: