This commits adds a method to the `std::process` module to get the process
identifier of the child as a `u32`. On Windows the underlying identifier is
already a `u32`, and on Unix the type is typically defined as `c_int` (`i32` for
almost all our supported platforms), but the actually pid is normally a small
positive number.
Eventually we may add functions to load information about a process based on its
identifier or the ability to terminate a process based on its identifier, but
for now this function should enable this sort of functionality to exist outside
the standard library.
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.
Using regular pointer arithmetic to iterate collections of zero-sized types
doesn't work, because we'd get the same pointer all the time. Our
current solution is to convert the pointer to an integer, add an offset
and then convert back, but this inhibits certain optimizations.
What we should do instead is to convert the pointer to one that points
to an i8*, and then use a LLVM GEP instructions without the inbounds
flag to perform the pointer arithmetic. This allows to generate pointers
that point outside allocated objects without causing UB (as long as you
don't dereference them), and it wraps around using two's complement,
i.e. it behaves exactly like the wrapping_* operations we're currently
using, with the added benefit of LLVM being able to better optimize the
resulting IR.
