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
Choose different name for metadata obj-file to avoid clashes with user-chosen names.
Fixes#39585 and probably https://github.com/rust-lang/rust/issues/39508.
Incremental compilation assigns different names to obj-files than regular compilation. If a crate is called "metadata" this can lead to a clash between the root module's obj-file and the obj-file containing crate-metadata. This PR assigns a name to the metadata obj-file that cannot clash with other obj-file because it contains a `.` which is not allowed in a Rust module identifier.
r? @alexcrichton
cc @nikomatsakis
Emit DW_AT_main_subprogram
This changes rustc to emit DW_AT_main_subprogram on the "main" program.
This lets gdb suitably stop at the user's main in response to
"start" (rather than the library's main, which is what happens
currently).
Fixes#32620
r? michaelwoerister
build std for sparc64-unknown-linux-gnu
r? @alexcrichton
panicking / unwinding is broken (#39646) but with std available at least people
will be able to debug that issue on real hardware
Improve format float
* Move float into mod float like in test
* Add more tests for f64 f32, lower exp, upper exp, which can come if handy in the future if we want refactor further
* Use `assert_eq` for clearer error messages
Make reprs use a structured representation instead of a slice
This is needed for `-z reorder-fields`. The old design uses a slice taken from HIR, plus a cache that lazily parses. The new design stores it directly in the `AdtDef` as a `ReprOptions`. We're doing this now because we need to be able to add reprs that don't necessarily exist in HIR for `-z reorder-fields`, but it needs to happen anyway.
`lookup_repr_hints` should be mostly deprecated. I want to remove it from `layout` before closing this, unless people think that should be a separate PR. The `[WIP]` is because of this. The problem with closing this as-is is that the code here isn't actually testable until some parts of the compiler start using it.
r? @eddyb
Stabilize static lifetime in statics
Stabilize the "static_in_const" feature. Blockers before this PR can be merged:
* [x] The [FCP with inclination to stabilize](https://github.com/rust-lang/rust/issues/35897#issuecomment-270441437) needs to be over. FCP lasts roughly three weeks, so will be over at Jan 25, aka this thursday.
* [x] Documentation needs to be added (#37928)
Closes#35897.
