Add Emscripten-specific linker
Emscripten claims to accept most GNU linker options, but in fact most of `-Wl,...` are useless for it and instead it requires some additional special options which are easier to handle in a separate trait.
Currently added:
- `export_symbols`: works on executables as special Emscripten case since staticlibs/dylibs aren't compiled to JS, while exports are required to be accessible from JS.
Fixes#39171.
- `optimize` - translates Rust's optimization level to Emscripten optimization level (whether passed via `-C opt-level=...` or `-O...`).
Fixes#36899.
- `debuginfo` - translates debug info; Emscripten has 5 debug levels while Rust has 3, so chose to translate `-C debuginfo=1` to `-g3` (preserves whitespace, variable and function names for easy debugging).
Fixes#36901.
- `no_default_libraries` - tells Emscripten to exclude `memcpy` and co.
TODO (in future PR): dynamic linking via `SIDE_MODULE` / `MAIN_MODULE` mechanism.
Conversions between slices and boxes
This allows conversion for `Copy` slices, `str`, and `CStr` into their boxed counterparts.
This also adds the method `CString::into_boxed_c_str`.
I would like to add similar implementations for `OsStr` as well, but I have not figured out how.
Previously it used to build a switch in a way that didn’t preserve the invariat of SwitchInt. Now
it builds it in an optimal way too, where otherwise branch becomes all the branches which did not
have partial variant drops.
This removes another special case of Switch by replacing it with the more general SwitchInt. While
this is more clunky currently, there’s no reason we can’t make it nice (and efficient) to use.
Previously AdtDef variants contained ConstInt for each discriminant, which did not really reflect
the actual type of the discriminants. Moving the type into AdtDef allows to easily put the type
into metadata and also saves bytes from ConstVal overhead for each discriminant.
Also arguably the code is cleaner now :)
It claims to accept most GNU linker options, but in fact most of them
have no effect and instead it requires some special options which are
easier to handle in a separate trait.
Currently added:
- `export_symbols`: works on executables as special Emscripten case
since staticlibs/dylibs aren't compiled to JS, while exports are
required to be accessible from JS.
Fixes#39171.
- `optimize` - translates Rust's optimization level to Emscripten
optimization level (whether passed via `-C opt-level=...` or `-O...`).
Fixes#36899.
- `debuginfo` - translates debug info; Emscripten has 5 debug levels
while Rust has 3, so chose to translate `-C debuginfo=1` to `-g3`
(preserves whitespace, variable and function names for easy debugging).
Fixes#36901.
- `no_default_libraries` - tells Emscripten to exlude `memcpy` and co.
The `Iterator.nth()` documentation says "Note that all preceding elements will be consumed". I assumed from that that the preceding elements would be the *only* ones that were consumed, but in fact the returned element is consumed as well.
The way I read the documentation, I assumed that `nth(0)` would not discard anything (as there are 0 preceding elements), so I added a sentence clarifying that it does. I also rephrased it to avoid the stunted "i.e." phrasing.
name anonymous fn parameters in libcore traits
This follows the discussion in rust-lang/rfcs#1685. The patch gives names to anonymous parameters in libcore traits. It would have two benefits I can think of: firstly it would provide names to tools that can use the names from the traits, and secondly core/std can serve as an example when writing traits; this change helps by not encouraging the use of anonymous parameters.
rustbuild: support setting verbosity in config.toml
Most if not all the configuration is settable trhough config.toml but the verbosity isn't yet.
This avoids having to pass -v to x.py on each command if you want verbosity to be always on.
I spent a good chunk of time tracking down a buffer overrun bug that
resulted from me mistakenly thinking that `reserve` was based on the
current capacity not the current length. It would be helpful if this
were called out explicitly in the docs.