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.

Sign up for GitHub

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

Jump to bottom

rustc happily compiles non-boolean branch expressions which assert at runtime #578

Closed
jdm opened this issue Jun 25, 2011 · 2 comments
Closed

rustc happily compiles non-boolean branch expressions which assert at runtime #578

jdm opened this issue Jun 25, 2011 · 2 comments
Assignees
@brson

Comments

@jdm
Copy link
Contributor

jdm commented Jun 25, 2011

auto a = 0u;
if (a) {
fail
}

This should be caught at compile time.
@ghost ghost assigned brson Jun 25, 2011
@brson
Copy link
Contributor

brson commented Jun 26, 2011

This should have been fixed by e8228e1 and I can't reproduce it with the latest. jdm, do you have the latest revision or can you provide more details?

@jdm
Copy link
Contributor Author

jdm commented Jun 26, 2011

Sorry, I'm using an old revision.

@jdm jdm closed this as completed Jun 26, 2011
keeperofdakeys pushed a commit to keeperofdakeys/rust that referenced this issue Dec 12, 2017
@bors
Auto merge of rust-lang#578 - cactorium:master, r=alexcrichton
19f3be3 
Steps towards support for musl-unknown-linux-uclibc

Hello! I've been working towards resolving rust-lang/libc#361 , this PR compiles successfully with a newish compiler (with some minor fixes in `gcc`, `ctest`), and all the tests pass for `libc-ctest`. Basically most of the undefined functions, constants, and structs were just removed from the ctest, and then any constants that weren't correct were fixed. Would it make more sense to conditionally remove them from libc? I wasn't sure when it was appropriate to skip the test for it instead of removing the function/constants, so I just removed all the tests for now because that was a little easier than hunting them down. I'm also guessing the way some of the constants were conditionally set wasn't the correct style, would you guys have any advice on how to do it more correctly? Lemme know how it looks!
keeperofdakeys pushed a commit to keeperofdakeys/rust that referenced this issue Dec 12, 2017
@bors
Auto merge of rust-lang#597 - PlasmaPower:bump-version, r=alexcrichton
7db3fd5 
Bump to 0.2.23

I've added a bunch of constants and xattr support for macos. We've also got preliminary support for uclibc with rust-lang#578.
flip1995 pushed a commit to flip1995/rust that referenced this issue Nov 3, 2020
@achris
Lint items after statements in macro expansions
32e2021 
The items_after_statements lint was skipping all expansions.  Instead
we should still lint local macros.

Fixes rust-lang#578
flip1995 pushed a commit to flip1995/rust that referenced this issue Nov 3, 2020
@bors
Auto merge of rust-lang#6176 - achris:issues/578, r=phansch
ee9da9a 
Lint items after statements in local macro expansions

The items_after_statements lint was skipping all expansions.  Instead
we should still lint local macros.

Fixes rust-lang#578

---

*Please keep the line below*
changelog: The items_after_statements now applies to local macro expansions
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@brson brson

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jdm @brson