Fix the link to the "static initialization order fiasco" discussion in the C++ Frequently Questioned Answers.
At present the link points to a mail message summarizing the decision not to have resumable exceptions, but the FAQ means to refer to a discussion of the "static initialization order fiasco". I've made my best guess at what it meant to refer to.
The Traits chapter uses "adding methods to `int`" as an example of "something bad", but there is no such thing as `int` anymore, right? So I changed it to `i32`.
The download links of Windows installers on the Nightly Rust page are using beta builds instead of nightly builds, which caused some confusions when I was setting up my env. Probably it's better to use the links of nightly builds here.
The Traits chapter uses "adding methods to `int`" as an example of "something bad", but there is no such thing as `int` anymore, right? So I changed it to `i32`.
The recent quote changes unfortunately broke unquoting statements like `let foo = 5` because the parser requires their to be a trailing semicolon in those statements. Along the way I added support for unquoting generics and where clauses as well as better pretty printing of `token::Interpolated`.
The download links of Windows installers on the Nightly Rust page are using beta builds instead of nightly builds, which caused some confusions when I was setting up my env. Probably it's better to use the links of nightly builds here.
The assume intrinsic has a strong, negative impact on compile times, so
we're currently only using it in places where LLVM can simplify it to
nonnull metadata on a load intruction. Unfortunately a recent change
that fixed invalid assume calls introduce new assume calls for which
this simplification can not happen, leading to a massive regression in
compile times in certain cases.
Moving the assumptions from the middle of the function to the beginning
allows the simplification to happen again, bringing compile times back
to their old levels.
Fixes#25393
The assume intrinsic has a strong, negative impact on compile times, so
we're currently only using it in places where LLVM can simplify it to
nonnull metadata on a load intruction. Unfortunately a recent change
that fixed invalid assume calls introduce new assume calls for which
this simplification can not happen, leading to a massive regression in
compile times in certain cases.
Moving the assumptions from the middle of the function to the beginning
allows the simplification to happen again, bringing compile times back
to their old levels.
Fixes#25393
I fixed the typo of the value of e in the memory tables. It is a reference to d, and so it should contain the memory location of d. I also fixed the incorrectly formatted tables so they display properly in html pages.
