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`.
Reported by Moonlightning on #rust
> 17:13 EDT < Moonlightning> I think I found a bug in the str::matches() documentation. Was it copied from str::split()? :p
> 17:13 EDT < Moonlightning> Because it says “The pattern can be a simple `&str`, `char`, or a closure that determines the split.”
I changed "determines the split" to "determines if a character matches".
It's not super clear, "determines the split" is not super clear to begin with, maybe this can be made better? On the other hand following the link to Pattern provides enough details.
separate use code between openbsd/netbsd
netbsd use c_int and c_uint, but openbsd not, resulting a unused_import
error.
r? @alexcrichton
problem introduced by #28543
This adds a new target property, `target_vendor` which can be used as a
matcher for conditional compilation. The vendor is part of the autoconf
target triple: <arch><sub>-<vendor>-<os>-<env>
The default value for `target_vendor` is "unknown".
Matching against the `target_vendor` with `#[cfg]` is currently feature
gated as `cfg_target_vendor`.
extend the search path of libraries to /usr/local/lib in `run-make`
testsuite. It should permit to find libstdc++.so on usual directory.
r? @alexcrichton
We don't actually probe for javac in all circumstances, so if you have
javac installed, but don't have antlr4 installed, and you're on Mac OS
X, then you'll get a message that javac is missing, even though that's
wrong.
To fix this, let's just be a bit more generic in the message, so that
it's the same no matter what part of the lexer tests you're missing.
cc
https://www.reddit.com/r/rust/comments/3m199d/running_make_check_on_the_source_code_says_javac/
We don't actually probe for javac in all circumstances, so if you have
javac installed, but don't have antlr4 installed, and you're on Mac OS
X, then you'll get a message that javac is missing, even though that's
wrong.
To fix this, let's just be a bit more generic in the message, so that
it's the same no matter what part of the lexer tests you're missing.
cc
https://www.reddit.com/r/rust/comments/3m199d/running_make_check_on_the_source_code_says_javac/
