-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Convert libstd to use the Drop trait #3962
Conversation
Working towards #3944 |
I suspect that the issue you are seeing is because of this rule: https://github.com/mozilla/rust/blob/incoming/mk/tests.mk#L95. If |
Merged. |
Thanks, @bstrie |
reverted. std tests aren't working on windows: http://bot.rust-lang.org/logs/2012/10/14/2012-11-14T22:43:24Z-be9c7d89-c6cf-4ae8-9883-a8ff03578c82.html |
thread_pool is the culprit |
I changed thread_pool back to drop blocks and pushed the rest to incoming |
fix a false positive in two `interior_mutable_const` lints where a constant with enums gets linted even if it uses a clearly unfrozen variant. Note that the code uses the MIR interpreter, which the author of rust-lang#3962 thought unlikely to be a solution. This might be over-engineering; but, I think it's important to be able to work with the 'http' crate (rust-lang#3825).
…=llogiq "Respect" enums in `interior_mutable_const` fixes rust-lang#3962 fixes rust-lang#3825 Hello, It might not be a good idea to submit another relatively large PR while I have an opened PR; but, I've finished this anyway. This may be able to wait for months. Note: the code uses the MIR interpreter, which the author of rust-lang#3962 thought unlikely to be a solution. This might be over-engineering; but, I think it's important to be able to work with the 'http' crate (rust-lang#3825). (And, I don't want to write a MIR visitor) --- changelog: fix a false positive in two `interior_mutable_const` lints where a constant with enums gets linted even if it uses a clearly unfrozen variant
With this code I've seen some intermittent failures when running
make -j8 check
. pcwalton seems to think this is to do with some parallel check going wrong, as I can't seem to reproduce the errors with just a usualmake check
(but they're nondeterministic errors in the first place, so that doesn't really say much). So there could be something lurking in here, but it's beyond my ken to track it down.