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.
Fix unsafe unaligned loads in test.
r? @eddyb
cc @Aatch @nikomatsakis
The `#[derive(PartialEq, Debug)]` impls on a packed struct contain undefined behaviour. Both generated impls take references to unaligned fields, which will fail to compile once we correctly treat that as unsafe (see https://github.com/rust-lang/rust/issues/27060).
This UB was found by running the test under [Miri](https://github.com/solson/miri/) which rejects these unsafe unaligned loads. 😄
Here's a simpler example:
```rust
struct Packed {
a: u8,
b: u64,
}
```
It expands to:
```rust
fn fmt(&self, __arg_0: &mut ::std::fmt::Formatter) -> ::std::fmt::Result {
match *self {
Packed { a: ref __self_0_0, b: ref __self_0_1 } => { // BAD: these patterns are unsafe
let mut builder = __arg_0.debug_struct("Packed");
let _ = builder.field("a", &&(*__self_0_0));
let _ = builder.field("b", &&(*__self_0_1));
builder.finish()
}
}
}
```
and
```rust
fn eq(&self, __arg_0: &Packed) -> bool {
match *__arg_0 {
Packed { a: ref __self_1_0, b: ref __self_1_1 } => // BAD: these patterns are unsafe
match *self {
Packed { a: ref __self_0_0, b: ref __self_0_1 } => // BAD: these patterns are unsafe
true && (*__self_0_0) == (*__self_1_0) &&
(*__self_0_1) == (*__self_1_1),
},
}
}
```
Exclude top-level macro expansions from source location override.
It occurred to me that a simple heuristic can address the issue #36382: any macros that expand into items (including `include!()`) don't need to be stepped over because there's not code to step through above a function scope level.
r? @michaelwoerister
