The notation I'm using isn't as specific as 'human name in square brackets'. It's the more standard approach editorial approach used to add context when pulling out a quote.
If you read the original text the context would be obvious but with the quote on its own it doesn't make sense so you want to add that context back in. That's done in square brackets to indicate that it is added and not part of the original quote.
The syntax is used where you're quoting text, but you're replacing some text with other text for explanatory purposes. So, for example, if the original quote was:
> The majority, however, uses this factor to create a distinction between declaring and implementing code that in effect removes copyright protection from declaring code.
Standing alone, you might not realize what "this" refers to. Instead, you'd substitute an explanation:
> The majority, however, uses [the nature of copyrighted work] factor to create a distinction between declaring and implementing code that in effect removes copyright protection from declaring code.
In practice, one of the most common replacements is replacing a pronoun with a name. So "his" becomes "[John Doe's]".
LLD is substantially faster than gold (largely because it does multithreading vastly better, but for other reasons as well, LLD discards some long-held linking semantics in the name of speed).
It took a ground-up rewrite to make it so. Rui Ueyama was employed by Google while he wrote LLD for ELF--it was his primary assignment, bought and paid for by Google.
So Google didn't just wait. It moved on to the next step.
Semantics? I know that LLD discarded the all-format architecture of gnu ld; arguably it got that idea from gold which is ELF only. But what semantics did it discard?
I'm a huge fan of LLD by the way. But in addition to performance and its implementation architecture, I think licensing had something to do with LLD's success.
> The semantics of LLD’s archive handling are different from the traditional Unix’s. You can observe it if you carefully craft archive files to exploit it. However, in reality, we don’t know any program that cannot link with our algorithm so far, so it’s not going to cause trouble.
I run into issues with these updated semantics not exactly routinely, but with some regularity. They can always be fixed, but often it is an annoying hassle.
Ian started work on gold in 2006, before clang existed, and well before any work had started on lld. Gold was released publicly in 2008 and I believe used internally at Google before that. LLD development didn't really get started until 2015 and wasn't really usable in large projects until 2016.
There was an earlier 2012 LLD [1] but it was an atom-based monolithic ELF/COFF/Mach-O. Rui Ueyama's LLD kept the name (it's a good name) but maybe that's about it. It has separate ELF, COFF + Mach-O implementations but with a similar architecture.
I mean if google had waited on starting gold. It was a time period before the dominance of LLVM but after doubts were growing about GNU tools; I am saying I am not at all surprised any tooling Google did from them would become abandonware.
A New ELF Linker
https://storage.googleapis.com/pub-tools-public-publication-...
Gold
https://www.airs.com/ian/gold-slides.pdf