Skip to content

Fix issue #666 #14631

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

Closed
wants to merge 1 commit into from
Closed

Fix issue #666 #14631

wants to merge 1 commit into from

Conversation

mcpherrinm
Copy link
Contributor

Add new ☢ keyword for unsafe blocks

@lilyball
Copy link
Contributor

lilyball commented Jun 3, 2014

Is it April 1st already?

@chris-morgan
Copy link
Member

If you were serious about this, you would have put mention of it in the documentation. This also doesn’t do all of #666 inasmuch as it does not alter the pretty printer.

@mcpherrinm
Copy link
Contributor Author

Though this may not have been the world's most serious pull request, I am a
little confused as to why the TravisCI build failed. It's complaining
about Hazard being unknown, but it seems to work just fine for me locally.
Can anyone help me understand why this failed?

On Tue, Jun 3, 2014 at 4:28 PM, Chris Morgan notifications@github.com
wrote:

If you were serious about this, you would have put mention of it in the
documentation. This also doesn’t do all of #666
#666 inasmuch as it does not
alter the pretty printer.


Reply to this email directly or view it on GitHub
#14631 (comment).

@lilyball
Copy link
Contributor

lilyball commented Jun 4, 2014

The Travis build because your PR does not define keywords::Hazard. Did you forget to include a file?

Also, if you were serious about this, #666 was rejected 2.5 years ago.

@mcpherrinm
Copy link
Contributor Author

Oh, whoops, forgot to commit one of the changes. No wonder it only works locally.

Add new ☢ keyword for unsafe blocks
@alexcrichton
Copy link
Member

As much as I'd love to push through the reform to add a radioactive symbol to keyboards, I have a feeling we may have a hard time convincing others.

I think we'll stick with the same resolution of #666 though, but perhaps we can consider this in the future!

@bstrie
Copy link
Contributor

bstrie commented Jun 4, 2014

Perhaps we could consider feature-gating behind a lint pass, #![allow(fun)]. The default would be #![deny(fun)], of course.

bors pushed a commit to rust-lang-ci/rust that referenced this pull request May 21, 2025
The `explicit_into_iter_loop`, `explicit_iter_loop` and `iter_next_loop`
will now:

- trigger only when the triggering expression is not located into macro
code;
- properly expose code rewrite proposal with code coming from the root
context.

changelog: [`explicit_into_iter_loop`, `explicit_iter_loop`,
`iter_next_loop`]: behave in macro context

Fixes rust-lang/rust-clippy#14630
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