Fix inner attribute syntax from #[foo]; to #![foo]
#13311
Conversation
From the 0.10 changelog: * The inner attribute syntax has changed from `#[foo];` to `#![foo]`.
|
There is something odd here: Travis CI says it's OK, while 'make check' on my system returns with errors: https://tim.siosm.fr/downloads/rust_tests_patched_rebased.log |
Maybe you hit some sort of resource exhaustion on your system? |
|
@kballard: Well, this is unlikely, as I've got 16GB RAM and 500GB free disk space on this system. Especially since Travis CI instances are supposed limited to be 3GB RAM. I'll have a look at the system status while running the tests next time. |
|
@Siosm There are more resources than just RAM. Maybe you hit some other limit (e.g. fd limit)? |
|
@kballard: I've got standard Linux limits: Should I raise any one of those in particular? I found nothing in the doc so far (https://github.com/mozilla/rust/wiki/Note-testsuite). I'm trying: |
|
@Siosm I have no idea. It was just a guess, but upon re-reading your error, the message is "Resource temporarily unavailable" which I believe actually comes from |
|
@kballard: I think it's a libuv bug because the test harness still uses libgreen. I run into it all the time too, so I can't run the tests anymore. From watching it in strace, it certainly gets a lot of |
This is not true.
It would be nice to report this then. |
|
rust/src/libstd/comm/mod.rs:437 > |
|
@alexcrichton: So running |
|
@Siosm I don't see that. The documentation of |
|
stdtest does use libgreen, you said "test harness", which is not true. The error was seen during nativetest. |
|
@kballard: My bad, I misread. I don't know what's the issue. Maybe it's related to the test. |
|
Based on the fact that it failed without having written what test it was trying to run, I believe it failed when trying to write |
|
I've got the results of 'make check RUST_TEST_TASKS=1': I forgot to update the pretty-printed source test. I'm having a look. |
|
After poking around for a while, I have to assume the error came from In any case, I have to assume that You could try redirecting the output to a file. |
|
@alexcrichton Any idea if my analysis is correct, and any answer as to why stdout would be marked |
|
That was exactly the conclusion I reached, and I have no idea why it would be set to non-blocking. |
|
I'm using Yakuake (Konsole). I'll try redirecting the output to a file. |
|
@alexcrichton I found a thread that indicates that non-blockingness of fds is actually a property of the underlying descriptor, and not of the per-process fd object. So a pseudo-TTY that is set to non-blocking from another process will become non-blocking in any process that uses the same device. So basically, whenever we're talking to TTYs they might be non-blocking. I have no idea what to do about this. I don't suppose there's a POSIX call that issues a write() (or a read()) in blocking mode even for non-blocking fds? |
|
Without a reliable method of reproduction, I'm wary to implement any fixes, but I would suspect that "just try 10 times in a row" would be sufficient for almost all use cases. |
|
@alexcrichton You could try creating a sample program that sets its stdin to O_NONBLOCK, then never reads, and write a Rust program that writes, say, 1MB to stdout (using libnative). Pipe them together and see what happens. |
|
Although now that I think about it, I would expect unix pipes to actually use separate underlying descriptor objects for each end. It's probably a PTTY-specific issue. |
|
May I suggest using a select (or select-like) call to wait on this specific issue? |
|
@alexcrichton I've come up with a 100% reliable reproduction method, where Rust never sets |
|
I've filed the issue as #13336. |
…Veykril fix: infer for-loop item type with `IntoIterator` and `Iterator` Part of rust-lang#13299 We've been inferring the type of the yielded values in for-loop as `<T as IntoIterator>::Item`. We infer the correct type most of the time when we normalize the projection type, but it turns out not always. We should infer the type as `<<T as IntoIterator>::IntoIter as Iterator>::Item`. When one specifies `IntoIter` assoc type of `IntoIterator` but not `Item` in generic bounds, we fail to normalize `<T as IntoIterator>::Item` (even though `IntoIter` is defined like so: `type IntoIter: Iterator<Item = Self::Item>` - rustc does *not* normalize projections based on other projection's bound I believe; see [this playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e88e19385094cb98fadbf647b4c2082e)). Note that this doesn't fully fix # 13299 - given the following code, chalk can normalize `<I as IntoIterator>::IntoIter` to `S`, but cannot normalize `<S as Iterator>::Item` to `i32`. ```rust struct S; impl Iterator for S { type Item = i32; /* ... */ } fn f<I: IntoIterator<IntoIter = S>>(it: I) { for elem in it {} //^^^^{unknown} } ``` This is because chalk finds multiple answers that satisfy the query `AliasEq(<S as Iterator>::Item = ?X`: `?X = i32` and `?X = <I as IntoIterator>::Item` - which are supposed to be the same type due to the aforementioned bound on `IntoIter` but chalk is unable to figure it out.
…ns, r=Manishearth Fix manual_range_patterns case with one element at OR Close rust-lang#11825 As mentioned rust-lang#11825 `OR` can be used for stylistic purposes with one element, we can filter this case from triggering lint changelog: [`manual_range_patterns`]: not trigger when `OR` has only one element
From the 0.10 changelog:
#[foo];to#![foo].I've run the tests, but I've got results I do not understand:
https://tim.siosm.fr/downloads/rust_tests_master.log (run on f819c21)
https://tim.siosm.fr/downloads/rust_tests_patched.log (run on f819c21 + patch; I've made a rebase since but did not rerun the checks)