Fixes#10302
I really am not sure I'm doing this right, so here goes nothing...
Also testing this isn't easy. I don't have any other *nix boxes besides a Linux one.
Test code:
```rust
use std::thread;
use std::io::timer::sleep;
use std::time::duration::Duration;
fn make_thread<'a>(i: i64) -> thread::JoinGuard<'a, ()>
{
thread::Builder::new().name(format!("MyThread{}", i).to_string()).scoped(move ||
{
println!("Start: {}", i);
sleep(Duration::seconds(i));
println!("End: {}", i);
})
}
fn main()
{
let mut guards = vec![make_thread(3)];
for i in 4i64..16
{
guards.push(make_thread(i));
}
}
```
GDB output on my machine:
```
(gdb) info threads
Id Target Id Frame
15 Thread 0x7fdfbb35f700 (LWP 23575) "MyThread3" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
14 Thread 0x7fdfba7ff700 (LWP 23576) "MyThread4" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
13 Thread 0x7fdfba5fe700 (LWP 23577) "MyThread5" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
12 Thread 0x7fdfba3fd700 (LWP 23578) "MyThread6" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
11 Thread 0x7fdfb8dfe700 (LWP 23580) "MyThread4" 0x00007fdfbb746193 in select () from /usr/lib/libc.so.6
10 Thread 0x7fdfb8fff700 (LWP 23579) "MyThread7" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
9 Thread 0x7fdfb8bfd700 (LWP 23581) "MyThread8" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
8 Thread 0x7fdfb3fff700 (LWP 23582) "MyThread9" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
7 Thread 0x7fdfb3dfe700 (LWP 23583) "MyThread10" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
6 Thread 0x7fdfb3bfd700 (LWP 23584) "MyThread11" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
5 Thread 0x7fdfb2bff700 (LWP 23585) "MyThread12" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
4 Thread 0x7fdfb29fe700 (LWP 23586) "MyThread13" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
3 Thread 0x7fdfb27fd700 (LWP 23587) "MyThread14" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
2 Thread 0x7fdfb1bff700 (LWP 23588) "MyThread15" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
* 1 Thread 0x7fdfbc411800 (LWP 23574) "threads" 0x00007fdfbbe2e505 in pthread_join () from /usr/lib/libpthread.so.0
```
(I'm not sure why one of the threads is duplicated, but it does that without my patch too...)
The usecase is that functions made visible to systems outside of the
rust ecosystem require the symbol to be visible.
This adds a lint for functions that are not exported, but also not mangled.
It has some gotchas:
[ ]: There is fallout in core that needs taking care of
[ ]: I'm not convinced the error message is correct
[ ]: It has no tests
~~However, there's an underlying issue which I'd like feedback on- which is that my belief that that non-pub functions would not have their symbols exported, however that seems not to be the case in the first case that this lint turned up in rustc (`rust_fail`), which intuition suggests has been working.~~
This seems to be a separate bug in rust, wherein the symbols are exported in binaries, but not in rlibs or dylibs. This lint would catch that case.
Coercions will now attempt to autoderef as needed before reborrowing.
This includes overloaded `Deref`, e.g. `&Rc<T>` coerces to `&T`, and
`DerefMut`, e.g. `&mut Vec<T>` coerces to `&mut [T]` (in addition to `&[T]`).
Closes#21432.
trans: When coercing to `Box<Trait>` or `Box<[T]>`, leave datum in it's original L-/R-value state.
This fixes a subtle issue where temporaries were being allocated (but not necessarily initialized) to the (parent) terminating scope of a match expression; in particular, the code to zero out the temporary emitted by `datum.store_to` is only attached to the particular match-arm for that temporary, but when going down other arms of the match expression, the temporary may falsely appear to have been initialized, depending on what the stack held at that location, and thus may have its destructor erroneously run at the end of the terminating scope.
FIx#20055.
(There may be a latent bug still remaining in `fn into_fat_ptr`, but I am so annoyed by the test/run-pass/coerce_match.rs failures that I want to land this now.)
It was considered to be impossible but actually it can
happen for nested closures. Also, because there must
be nested closures when this happens, we can use more
targeted help message.
Closes#21390Closes#21600
Note: Do not merge until we get a newer snapshot that includes #21374
There was some type inference fallout (see 4th commit) because type inference with `a..b` is not as good as with `range(a, b)` (see #21672).
r? @alexcrichton
