Change the behavior of the glue code emitted for `size_and_align_of_dst`.
This thus changes the behavior of `std::mem::size_of_val` and `std::mem::align_of_val`. It tries to move us towards a world where the following property holds:
Given type `T` implements `Trait` and a value `b: Box<T>`, where `std::mem::size_of::<T>()` returns `k`, then:
* `std::mem::size_of_val(b)` returns `k`
* `std::mem::size_of_val(b as Box<Trait>)` returns `k`
Note that one might legitimately question whether the above property *should* hold. The property certainly does not hold today, as illustrated by #27023.
(A follow-up task is to make various tests that check that the above property holds for a wide variety of types ... I chose not to invest effort in writing such a test before we actually determine that the above property is desirable.)
nmatsakis and pnkfelix agree that this PR does not require an RFC. cc @rust-lang/lang (since others may disagree).
(It also *might* break code, though it is hard for me to imagine that it could break code that wasn't already going to assert-fail when run in e.g. debug builds...)
Fix issue #27023
Also, this (or something like it) is a prerequisite for *fixing`make check` on `--enable-optimize --enable-debug` builds*
Add a new method `CommandExt::session_leader(&mut self, on: bool)` to create a new session (cf. `setsid(2)`) for the child process. This means that the child is the leader of a new process group. The parent process remains the child reaper of the new process.
This is not enough to create a daemon process. The *init* process should be the child reaper of a daemon. This can be achieved if the parent process exit. Moreover, a daemon should not have a controlling terminal. To acheive this, a session leader (the child) must spawn another process (the daemon) in the same session.
cc rust-lang/rfcs#941
cc #17176
This commit removes the injection of `std::env::args()` from `--test` expanded
code, relying on the test runner itself to call this funciton. This is more
hygienic because we can't assume that `std` exists at the top layer all the
time, and it meaks the injected test module entirely self contained.
We were burying the reason to use this function below a bunch of caveats about
its usage. That's backwards. Why a function should be used belongs at the top of
the docs, not the bottom.
Also, add some extra links to related functions mentioned in the body.
Some small changes to (hopefully) make search more useful:
* Less strict filtering, e.g:
* searching for "fn: foo" now matches methods and trait functions as well.
* searching for types also matches primitive types.
* searching for const will also match associated constants (but there aren't any in std yet)
* Changed searching for types to use the actual keyword "type" instead of the strange C-like "typedef".
* Added const and macro to allowed keywords.
- Move "Destructuring" after "Multiple patterns", because some of
later sections include examples which make use of destructuring.
- Move "Ignoring bindings" after "Destructoring", because the former
features Result<T,E> destructuring. Some of examples in later
sections use "_" and "..", so "Ignoring bindings" must be
positioned before them.
- Fix#27347 by moving "Ref and mut ref" before "Ranges" and
"Bindings", because "Bindings" section includes a somewhat
difficult example, which also makes use of "ref" and "mut ref"
operators.
The investigation into #14232 discovered that it's possible that signal delivery
to a newly spawned process is racy on OSX. This test has been failing spuriously
on the OSX bots for some time now, so ignore it as we don't currently know a
solution and it looks like it may be out of our control.
- Fix#26968 by noting the difference between ".." and "_" more explicitly
- Change one of the examples to show the match-all behaviour of ".."
- Merge "Ignoring variants" and "Ignoring bindings" sections into the latter
r? @steveklabnik
Clarifications for those new to Rust and Cargo:
* It's a good idea to get rid of the original `main.exe` in project root
* Slight clarification on the use of `main.rs` vs `lib.rs`
* Clarify that the TOML file needs to be in project root
This test case has been removed a while ago because it allegedly was broken. But I don't think it is (at least I couldn't reproduce any failure on Linux). Let's give it another chance `:)`
This commit is an implementation of [RFC 1184][rfc] which tweaks the behavior of
the `#![no_std]` attribute and adds a new `#![no_core]` attribute. The
`#![no_std]` attribute now injects `extern crate core` at the top of the crate
as well as the libcore prelude into all modules (in the same manner as the
standard library's prelude). The `#![no_core]` attribute disables both std and
core injection.
[rfc]: https://github.com/rust-lang/rfcs/pull/1184
After #26694, the overloaded operator and "impl not known at method lookup time" cases started triggering the lint.
I've also added checks for overloaded autoderef and method calls via paths (i.e. `T::method()`).
All new 8 test cases did not trigger the lint before #26694.
r? @huonw
Fixes#25022
This adapts the deriving mechanism to not repeat bounds for the same type parameter. To give an example: for the following code:
```rust
#[derive(Clone)]
pub struct FlatMap<I, U: IntoIterator, F> {
iter: I,
f: F,
frontiter: Option<U::IntoIter>,
backiter: Option<U::IntoIter>,
}
```
the latest nightly generates the following impl signature:
```rust
impl <I: ::std::clone::Clone,
U: ::std::clone::Clone + IntoIterator,
F: ::std::clone::Clone>
::std::clone::Clone for FlatMap<I, U, F> where
I: ::std::clone::Clone,
F: ::std::clone::Clone,
U::IntoIter: ::std::clone::Clone,
U::IntoIter: ::std::clone::Clone
```
With these changes, the signature changes to this:
```rust
impl <I, U: IntoIterator, F> ::std::clone::Clone for FlatMap<I, U, F> where
I: ::std::clone::Clone,
F: ::std::clone::Clone,
U::IntoIter: ::std::clone::Clone
```
(Nothing in the body of the impl changes)
Note that the second impl is more permissive, as it doesn't have a `Clone` bound on `U` at all. There was a compile-fail test that failed due to this. I don't understand why we would want the old behaviour (and nobody on IRC could tell me either), so please tell me if there is a good reason that I missed.
