rust/tests/ui/liveness/liveness-use-after-send.rs

use std::marker;

fn send<T:Send + std::fmt::Debug>(ch: Chan<T>, data: T) {
    println!("{:?}", ch);
    println!("{:?}", data);
    panic!();
}

#[derive(Debug)]
struct Chan<T>(isize, marker::PhantomData<T>);

// Tests that "log(debug, message);" is flagged as using
// message after the send deinitializes it
fn test00_start(ch: Chan<Box<isize>>, message: Box<isize>, _count: Box<isize>) {
    send(ch, message);
    println!("{}", message); //~ ERROR borrow of moved value: `message`
}

fn main() { panic!(); }
Fallout: tests. As tests frequently elide things, lots of changes here. Some of this may have been poorly rebased, though I tried to be careful and preserve the spirit of the test. 2015-02-12 15:29:52 +00:00			`use std::marker;`

make non_camel_case_types an early lint 2018-12-17 03:21:47 +00:00			`fn send<T:Send + std::fmt::Debug>(ch: Chan<T>, data: T) {`
core: split into fmt::Show and fmt::String fmt::Show is for debugging, and can and should be implemented for all public types. This trait is used with `{:?}` syntax. There still exists #[derive(Show)]. fmt::String is for types that faithfully be represented as a String. Because of this, there is no way to derive fmt::String, all implementations must be purposeful. It is used by the default format syntax, `{}`. This will break most instances of `{}`, since that now requires the type to impl fmt::String. In most cases, replacing `{}` with `{:?}` is the correct fix. Types that were being printed specifically for users should receive a fmt::String implementation to fix this. Part of #20013 [breaking-change] 2014-12-20 08:09:35 +00:00			`println!("{:?}", ch);`
			`println!("{:?}", data);`
Rename fail! to panic! https://github.com/rust-lang/rfcs/pull/221 The current terminology of "task failure" often causes problems when writing or speaking about code. You often want to talk about the possibility of an operation that returns a Result "failing", but cannot because of the ambiguity with task failure. Instead, you have to speak of "the failing case" or "when the operation does not succeed" or other circumlocutions. Likewise, we use a "Failure" header in rustdoc to describe when operations may fail the task, but it would often be helpful to separate out a section describing the "Err-producing" case. We have been steadily moving away from task failure and toward Result as an error-handling mechanism, so we should optimize our terminology accordingly: Result-producing functions should be easy to describe. To update your code, rename any call to `fail!` to `panic!` instead. Assuming you have not created your own macro named `panic!`, this will work on UNIX based systems: grep -lZR 'fail!' . \| xargs -0 -l sed -i -e 's/fail!/panic!/g' You can of course also do this by hand. [breaking-change] 2014-10-09 19:17:22 +00:00			`panic!();`
Register snapshots and switch logging over to use of log_full or #error / #debug. 2011-12-22 22:42:52 +00:00			`}`
Stop inferring bot/static when types/regions are unconstrained. Also, some other changes that came up along the way: - add a 'blk' region for the current block. - detect unused type/region variables. 2012-04-30 17:37:58 +00:00
std: Rename Show/String to Debug/Display This commit is an implementation of [RFC 565][rfc] which is a stabilization of the `std::fmt` module and the implementations of various formatting traits. Specifically, the following changes were performed: [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0565-show-string-guidelines.md * The `Show` trait is now deprecated, it was renamed to `Debug` * The `String` trait is now deprecated, it was renamed to `Display` * Many `Debug` and `Display` implementations were audited in accordance with the RFC and audited implementations now have the `#[stable]` attribute * Integers and floats no longer print a suffix * Smart pointers no longer print details that they are a smart pointer * Paths with `Debug` are now quoted and escape characters * The `unwrap` methods on `Result` now require `Display` instead of `Debug` * The `Error` trait no longer has a `detail` method and now requires that `Display` must be implemented. With the loss of `String`, this has moved into libcore. * `impl<E: Error> FromError<E> for Box<Error>` now exists * `derive(Show)` has been renamed to `derive(Debug)`. This is not currently warned about due to warnings being emitted on stage1+ While backwards compatibility is attempted to be maintained with a blanket implementation of `Display` for the old `String` trait (and the same for `Show`/`Debug`) this is still a breaking change due to primitives no longer implementing `String` as well as modifications such as `unwrap` and the `Error` trait. Most code is fairly straightforward to update with a rename or tweaks of method calls. [breaking-change] Closes #21436 2015-01-20 23:45:07 +00:00			`#[derive(Debug)]`
make non_camel_case_types an early lint 2018-12-17 03:21:47 +00:00			`struct Chan<T>(isize, marker::PhantomData<T>);`
Track arguments in typestate Add the infrastructure for arguments -- as well as local vars -- to be deinitialized with move-mode calls. Address Issue #819 2011-08-17 23:58:00 +00:00
Register new snapshots, purge log_err and log_full in favour of log(...). 2011-12-23 01:53:53 +00:00			`// Tests that "log(debug, message);" is flagged as using`
Track arguments in typestate Add the infrastructure for arguments -- as well as local vars -- to be deinitialized with move-mode calls. Address Issue #819 2011-08-17 23:58:00 +00:00			`// message after the send deinitializes it`
make non_camel_case_types an early lint 2018-12-17 03:21:47 +00:00			`fn test00_start(ch: Chan<Box<isize>>, message: Box<isize>, _count: Box<isize>) {`
Finalize moves-based-on-type implementation. Changes: - Refactor move mode computation - Removes move mode arguments, unary move, capture clauses (though they still parse for backwards compatibility) - Simplify how moves are handled in trans - Fix a number of illegal copies that cropped up - Workaround for bug involving def-ids in params (see details below) Future work (I'll open bugs for these...): - Improve error messages for moves that are due to bindings - Add support for moving owned content like a.b.c to borrow check, test in trans (but I think it'll "just work") - Proper fix for def-ids in params Def ids in params: Move captures into a map instead of recomputing. This is a workaround for a larger bug having to do with the def-ids associated with ty_params, which are not always properly preserved when inlining. I am not sure of my preferred fix for the larger bug yet. This current fix removes the only code in trans that I know of which relies on ty_param def-ids, but feels fragile. 2013-01-10 18:59:58 +00:00			`send(ch, message);`
update tests for migrate mode by default 2019-04-22 07:40:08 +00:00			println!("{}", message); //~ ERROR borrow of moved value: `message`
Track arguments in typestate Add the infrastructure for arguments -- as well as local vars -- to be deinitialized with move-mode calls. Address Issue #819 2011-08-17 23:58:00 +00:00			`}`

Rename fail! to panic! https://github.com/rust-lang/rfcs/pull/221 The current terminology of "task failure" often causes problems when writing or speaking about code. You often want to talk about the possibility of an operation that returns a Result "failing", but cannot because of the ambiguity with task failure. Instead, you have to speak of "the failing case" or "when the operation does not succeed" or other circumlocutions. Likewise, we use a "Failure" header in rustdoc to describe when operations may fail the task, but it would often be helpful to separate out a section describing the "Err-producing" case. We have been steadily moving away from task failure and toward Result as an error-handling mechanism, so we should optimize our terminology accordingly: Result-producing functions should be easy to describe. To update your code, rename any call to `fail!` to `panic!` instead. Assuming you have not created your own macro named `panic!`, this will work on UNIX based systems: grep -lZR 'fail!' . \| xargs -0 -l sed -i -e 's/fail!/panic!/g' You can of course also do this by hand. [breaking-change] 2014-10-09 19:17:22 +00:00			`fn main() { panic!(); }`