Fixed example threaded code in intro doc never printing results. Threads were created with Thread::spawn instead of Thread::scoped. Also added correct thread handling like in the first example of the document.
This is a patch for #17829.
In `compiletest` there are multiple layers which capture the output. The first layer is `run_tests_console` which is used to execute all tests.
Then there are some tests that contain unit tests, which by default also captures output. Therefore `compiletest` adds `RUST_TEST_NOCAPTURE` (and `RUST_TEST_TASKS` for completeness) to the run environment of the task.
Finally, the task used to execute a test redirects stdout and stdin. At the moment, the `VERBOSE=1` prints all captured output of the task (but has to print stdout and stderr separately). So at the moment using `RUST_TEST_NOCAPTURE=1` only makes sense when also using `VERBOSE=1` which seems a little bit cumbersome.
Should I update the patch to only print the output of the tasks that actually execute the test (`VERBOSE=1` includes other stuff, like the output of the task used to compile the test)? This will probably involve adding an extra flag to some functions in `src/compiletest/runtest.rs` to distinguish compilation runs from runs that execute the actual tests.
... to convert between Box and raw pointers. E. g. use
```
let b: Box<Foo> = Box::from_raw(p);
```
instead of
```
let b: Box<Foo> = mem::transmute(p);
```
Patch also changes closure release code in `src/libstd/sys/unix/thread.rs`
when `pthread_create` failed. Raw pointer was transmuted to box of
`FnOnce()` instead of `Thunk`. This code was probably never executed,
because `pthread_create` rarely fails in practice.
This is not a complete implementation of the RFC:
- only existing methods got updated, no new ones added
- doc comments are not extensive enough yet
- optimizations got lost and need to be reimplemented
See https://github.com/rust-lang/rfcs/pull/528
Technically a
[breaking-change]
Implements `append()` and `split_off()` for `VecMap`. It's worth noting
that `append()` will overwrite existing keys (the RFC doesn't specify how
`append()` should handle duplicate keys).
cc #19986
We already do this for the function arguments, but miss it for the
retslot pointer, which can lead to LLVM assertions because the retslot
has the wrong type.
Fixes#22663