Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rusti: Cannot print not-implicitly-copyable variables #7692

Closed
gifnksm opened this issue Jul 10, 2013 · 2 comments · Fixed by #9897
Closed

rusti: Cannot print not-implicitly-copyable variables #7692

gifnksm opened this issue Jul 10, 2013 · 2 comments · Fixed by #9897

Comments

@gifnksm
Copy link
Contributor

gifnksm commented Jul 10, 2013

$ rusti                                                                                                              (git)-[master] -
WARNING: The Rust REPL is experimental and may be
unstable. If you encounter problems, please use the
compiler instead. Type :help for help.
rusti> let v = ~[1,2,3];
rusti> v
<anon>:43:36: 43:37 error: use of moved value: `v`
<anon>:43                 let local: ~[int] = v;
                                              ^
<anon>:41:0: 41:1 note: `v` moved here because it has type `~[int]`, which is moved by default (use `copy` to override)
<anon>:41 v
          ^
error: aborting due to previous error
rust: task failed at 'explicit failure', /home/nksm/pkg/rust/src/rust/src/libsyntax/diagnostic.rs:95

I think rusti should prints the value of v.

@gifnksm
Copy link
Contributor Author

gifnksm commented Jul 10, 2013

workaround for this issue.

rusti> let v = ~[1,2,3];
rusti> copy v
~[1, 2, 3]

@alexcrichton
Copy link
Member

I was thinking about this awhile back. I think that the best way to go about doing this would be to just don't re-serialize moved variables. Basically after the user-input code is executed, detect if any of the local bound variables were moved, and don't reserialize them.

The bad part is that you can move out of a variable and then use it in a later statement, but this is purely a debugging repl so I don't think that it's too bad.

bors added a commit that referenced this issue Oct 17, 2013
Closes #9818
Closes #9567
Closes #8924
Closes #8910
Closes #8392
Closes #7692
Closes #7499
Closes #7220
Closes #5038
flip1995 pushed a commit to flip1995/rust that referenced this issue Sep 28, 2021
…giraffate

Demote float_cmp to pedantic

See this issue: rust-lang/rust-clippy#7666

This is one of the most frequently suppressed lints. It is deny-by-default. It is not actually clearly wrong, as there are many instances where direct float comparison is actually desirable. It is only after operating on floats that they may lose precision, and that depends greatly on the operation. As most correctness lints have a much higher standard of error, being based on hard and fast binary logic, this should not be amongst them.

A linter is not a substitute for observing the math carefully and running tests, and doing the desirable thing is even more likely to lead one to want exact comparisons.

changelog: Demote [`float_cmp`] from correctness to pedantic lints
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants