LLVM_EXTERNAL_CLANG_TOOLS_EXTRA_SOURCE_DIR was removed in https://reviews.llvm.org/D58157, so it's unset by default.

Firefox CI is using a custom clang, but uses a NDK otherwise (an old-ish one, clearly older than r22 which is the first that defaults to lld). And we do pass -fuse-ld=bfd at the moment for $reasons.
If clang _really_ wants to assume lld as the linker for android, then it should make using -fuse-ld=somethingelse an error and invoke ld.lld rather than ld, if it doesn't already do that.

"Android only supports lld" might be true now, but it hasn't always been true, which means the change is not backwards compatible with versions of the NDK that don't use lld. Also, -fuse-ld is still a valid flag that can allow to use a different linker than lld.

FWIW, when applying this patch on a LLVM10-based rustc, the rustc build fails with:

PHI node has multiple entries for the same basic block with different incoming values!
  %35 = phi { i64*, i32 }* [ %83, %77 ], [ %84, %77 ], [ %33, %2 ]
label %77
  %83 = getelementptr { i64*, i32 }, { i64*, i32 }* %35, i64 -1
  %84 = getelementptr { i64*, i32 }, { i64*, i32 }* %35, i64 -1
in function _ZN80_$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$alloc..vec..SpecExtend$LT$T$C$I$GT$$GT$9from_iter17h62b0d0798a862a64E
LLVM ERROR: Broken function found, compilation aborted!
error: could not compile `rustc_typeck`.

In D57636#1389971, @efriedma wrote:

LGTM. Do you want me to commit this for you?

@efriedma can you take another look? Ideally, this should be backported to the release_80 branch, so that would need to be landed asap.

Updated EmitAArch64BuiltinExpr per https://reviews.llvm.org/D57636#1383751 and the testcase per https://reviews.llvm.org/D57636#1384348

In D57636#1383566, @efriedma wrote:

(It should be possible to check that we aren't inserting incorrect truncation/extension operations in the IR.)

Opened D57636

In D51204#1271564, @dmajor wrote:

In D51204#1253230, @mgrang wrote:

Will abandon this patch since I have implementations of these which I will upstream soon.

Just to link up the reviews: these landed in D52838 and D53115. (Thanks @mgrang!)

In D54891#1311086, @olista01 wrote:

I can provide a full log of the 4831 warnings marked -Winline-asm during a Firefox for ARM Android build, if you're interested.

Yes, it would be helpful if you could send me that output (with the latest patch applied).

Correction, the mpi_arm.c ones seem to be caught. However, warnings are also being emitted for assembly post substitution. Example:

Assuming removing the variadicOpsAreDefs test completely (since I couldn't figure where it came from) still yields something that mostly works, it appears not to catch when the assembly writes to input operands. Examples of real code that had the problem:

• https://hg.mozilla.org/projects/nss/rev/09ab3310e71028dbdbf6846289cb4d3cea249534
• https://hg.mozilla.org/mozilla-central/rev/e471c532fd11

Updated wording.