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

rustc: update the unnecessary parens lint for struct literals. #15157

Closed
wants to merge 8 commits into from

Conversation

huonw
Copy link
Member

@huonw huonw commented Jun 24, 2014

rustc: update the unnecessary parens lint for struct literals.

Things like match X { x: 1 } { ... } now need to be written with
parentheses, so the lint should avoid warning in cases like that.

@huonw huonw changed the title rustc: update the unnecessary paren lint for struct literals. rustc: update the unnecessary parens lint for struct literals. Jun 24, 2014
@huonw
Copy link
Member Author

huonw commented Jun 25, 2014

This isn't quite right (e.g. match box X { x: 1 } { ... } needs parens too), I'll update it.

@huonw huonw closed this Jun 25, 2014
alexcrichton and others added 8 commits June 26, 2014 12:40
Most of the comments are available on the Task structure itself, but this commit
is aimed at making FFI-style usage of Rust tasks a little nicer.

Primarily, this commit enables re-use of tasks across multiple invocations. The
method `run` will no longer unconditionally destroy the task itself. Rather, the
task will be internally re-usable if the closure specified did not fail. Once a
task has failed once it is considered poisoned and it can never be used again.

Along the way I tried to document shortcomings of the current method of tearing
down a task, opening a few issues as well. For now none of the behavior is a
showstopper, but it's useful to acknowledge it. Also along the way I attempted
to remove as much `unsafe` code as possible, opting for safer abstractions.
…brson

Most of the comments are available on the Task structure itself, but this commit
is aimed at making FFI-style usage of Rust tasks a little nicer.

Primarily, this commit enables re-use of tasks across multiple invocations. The
method `run` will no longer unconditionally destroy the task itself. Rather, the
task will be internally re-usable if the closure specified did not fail. Once a
task has failed once it is considered poisoned and it can never be used again.

Along the way I tried to document shortcomings of the current method of tearing
down a task, opening a few issues as well. For now none of the behavior is a
showstopper, but it's useful to acknowledge it. Also along the way I attempted
to remove as much `unsafe` code as possible, opting for safer abstractions.
We use re-exported pathes (e.g. std::io::Command) and original ones
(e.g. std::io::process::Command) together in examples now. Using
re-exported ones consistently avoids confusion.

Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
Since procs do not have lifetime bounds, we must do this to maintain
safety.

This can break code that incorrectly captured references in procedure
types. Change such code to not do this, perhaps with a trait object
instead.

A better solution would be to add higher-rank lifetime support to procs.
However, this would be a lot of work for a feature we want to remove in
favor of unboxed closures. The corresponding "real fix" is rust-lang#15067.

Closes rust-lang#14036.

[breaking-change]
…hton

Since procs do not have lifetime bounds, we must do this to maintain
safety.

This can break code that incorrectly captured references in procedure
types. Change such code to not do this, perhaps with a trait object
instead.

Closes rust-lang#14036.

[breaking-change]

r? @alexcrichton
…crichton

We use re-exported pathes (e.g. std::io::Command) and original ones
(e.g. std::io::process::Command) together in examples now. Using
re-exported ones consistently avoids confusion.
Built on top of rust-lang#15181. steveklabnik@e527192 is the only new commit, you may want to review that separately.

I'm not sure if the car analogy is too glib.
Things like `match X { x: 1 } { ... }` now need to be written with
parentheses, so the lint should avoid warning in cases like that.
@huonw huonw reopened this Jun 27, 2014
@huonw huonw closed this Jun 27, 2014
@huonw huonw deleted the struct-paren-lint branch June 27, 2014 06:48
@huonw huonw restored the struct-paren-lint branch June 27, 2014 06:49
@huonw
Copy link
Member Author

huonw commented Jun 27, 2014

Github picked up a pile of random commits, so this is now over at #15212. (The exact same commit, not sure what happened. shrug)

@huonw huonw deleted the struct-paren-lint branch July 11, 2014 05:54
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 17, 2023
Fix runnable detection for `#[tokio::test]`

fix rust-lang#15141

It is hacky, and it wouldn't work for e.g. this case:
```Rust
use ::core::prelude;

#[prelude::v1::test]
fn foo() {
}
```
But it works for the tokio case. We should use the name resolution here somehow, and after that we should probably also get rid of the ast based `test_related_attribute` function.
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 this pull request may close these issues.

5 participants