This is mainly to avoid infinite recursion and make debugging more convenient in the anomalous case in which `on_panic` panics.
I encountered such issues while changing libstd to debug/fix part of #28129.
While writing this I was wondering about which functions belong to `panicking` and which to `unwind`.
I placed them in this way mostly because of convenience, but I would strongly appreciate guidance.
This adds a new target property, `target_vendor`. It is to be be used as a matcher for conditional compilation. The vendor is part of the [autoconf target triple](http://llvm.org/docs/doxygen/html/classllvm_1_1Triple.html#details): `<arch><sub>-<vendor>-<os>-<env>`. `arch`, `target_os` and `target_env` are already supported by Rust.
This change was suggested in PR #28593. It enables conditional compilation based on the vendor. This is needed for the rumprun target, which needs to match against both, target_os and target_vendor.
The default value for `target_vendor` is "unknown", "apple" and "pc" are other common values.
Matching against the `target_vendor` is introduced behind the feature gate `#![feature(cfg_target_vendor)]`.
This is the first time I messed around with rustc internals. I just added the my code where I found the existing `target_*` variables, hopefully I haven't missed anything. Please review with care. :)
r? @alexcrichton
This commit updates the compiler to not attempt to use jemalloc for platforms
where jemalloc is never enabled. Currently the compiler attempts to link in
jemalloc based on whether `--disable-jemalloc` was specified at build time for
the compiler itself, but this is only the right decision for the host target,
not for other targets.
This still leaves a hole open where a set of target libraries are downloaded
which were built with `--disable-jemalloc` and the compiler is unaware of that,
but this is a pretty rare case so it can always be fixed later.
This commit updates the `MatchIndices` and `RMatchIndices` iterators to follow
the same pattern as the `chars` and `char_indices` iterators. The `matches`
iterator currently yield `&str` elements, so the `MatchIndices` iterator now
yields the index of the match as well as the `&str` that matched (instead of
start/end indexes).
cc #27743
This makes the first lines of the print! and println! macros
different. Previously, they would show up exactly the same in the
documentation for the macros in libstd [1], with nothing about how
one of them also prints a newline.
[1]: https://doc.rust-lang.org/stable/std/#macros
By putting an "unreachable" instruction into the default arm of a switch
instruction we can let LLVM know that the match is exhaustive, allowing
for better optimizations.
For example, this match:
```rust
pub enum Enum {
One,
Two,
Three,
}
impl Enum {
pub fn get_disc(self) -> u8 {
match self {
Enum::One => 0,
Enum::Two => 1,
Enum::Three => 2,
}
}
}
```
Currently compiles to this on x86_64:
```asm
.cfi_startproc
movzbl %dil, %ecx
cmpl $1, %ecx
setne %al
testb %cl, %cl
je .LBB0_2
incb %al
movb %al, %dil
.LBB0_2:
movb %dil, %al
retq
.Lfunc_end0:
```
But with this change we get:
```asm
.cfi_startproc
movb %dil, %al
retq
.Lfunc_end0:
```
This should fix#22682.
"max-width: 1023px" seems like a good compromise here. This way,
1024x768 monitors will still see the sidebar (plus, iPad in landscape
mode).
There's no need for javascript.rs now that its contents were moved into
.js files.
Also, adjust a couple variable names and some indentation in build.rs.
The double-panic `abort` is run after the logging code, to provide
feedback in case of a double-panic. This means that if the panic
logging fails with a panic, the `abort` might never be reached.
This should not normally occur, but if the `on_panic` function detects
more than 2 panics, aborting *before* logging makes panic handling
somewhat more robust, as it avoids an infinite recursion, which would
eventually crash the process, but also make the problem harder to
debug.
This handles the FIXME about what to do if the thread printing panics.
Move the panic handling logic from the `unwind` module to `panicking`
and use a panic counter to distinguish between normal state, panics
and double panics.
Make sure Name, SyntaxContext and Ident are passed by value
Make sure Idents don't serve as keys (or parts of keys) in maps, Ident comparison is not well defined
[breaking-change]
`FixedSizeArray` is meant to be implemented for arrays of fixed size only, but can be implemented for anything at the moment. Marking the trait unsafe would make it more reasonable to write unsafe code which operates on fixed size arrays of any size.
For example, using `uninitialized` to create a fixed size array and immediately filling it with a fixed value is externally safe:
```
pub fn init_with_nones<T, A: FixedSizeArray<Option<T>>>() -> A {
let mut res = unsafe { mem::uninitialized() };
for elm in res.as_mut_slice().iter_mut() {
*elm = None;
}
res
}
```
But the same code is not safe if `FixedSizeArray` is implemented for other types:
```
struct Foo { foo: usize }
impl FixedSizeArray<Option<usize>> for Foo {
fn as_slice(&self) -> &[usize] { &[] }
fn as_mut_slice(&self) -> &mut [usize] { &mut [] }
}
```
now `init_with_nones() : Foo` returns a `Foo` with an undefined value for the field `foo`.
