For historical reasons, "Win32" has been used in Rust codebase to mean "Windows OS in general".
This is confusing, especially now, that Rust supports Win64 builds.
[breaking-change]
Implement `Index` for `RingBuf`, `HashMap`, `TreeMap`, `SmallIntMap`, and `TrieMap`.
If there’s anything that I missed or should be removed, let me know.
There was a bug in both libnative and libuv which prevented child processes from
being spawned correctly on windows when one of the arguments was an empty
string. The libuv bug has since been fixed upstream, and the libnative bug was
fixed as part of this commit.
When updating libuv, this also includes a fix for #15149.
Closes#15149Closes#16272
- Moved examples for permutations and next into trait definition as
comments on pull request #16244.
- Fixed (hopefully) issue with erronious commit of changes to src/llvm.
Since https://github.com/rust-lang/rust/pull/16380 didn't get pulled in yet, I added it in here too.
This covers the very, very, very basics of vectors. I wanted to have a section that mentioned them, but I'm
unsure what else I should cover. So I just did the absolute simplest things. Feedback very welcome.
Previously we would accept an empty log level without an equals sign, but not with one. This addresses that minor nit. E.g., `RUST_LOG=rustc::middle::trans=` will work the same as `RUST_LOG=rustc::middle::trans`.
- API doc/example for next() in Permutations
- API doc/example for permutations() in ImmutableCloneableVector
- Moved examples for permutations and next into trait definition as
comments on pull request #16244.
- Fix erroneus inclusion of src/llvm in older commit.
The fail macro defines some function/static items internally, which got
a dead_code warning when `fail!()` is used inside a dead function. This
is ugly and unnecessarily reveals implementation details, so the
warnings can be squashed.
Fixes#16192.
The fail macro defines some function/static items internally, which got
a dead_code warning when `fail!()` is used inside a dead function. This
is ugly and unnecessarily reveals implementation details, so the
warnings can be squashed.
Fixes#16192.
People reading the tutorial may not be familiar with the convention of naming lists, vectors and the like as xs, ys, etc. Without some explanation of the reasoning behind it, it might come off as just throwaway non-descriptive names. Languages like Haskell gets flak from using short, non-descriptive names, while in reality, there are clear conventions and reasons for using certain terse variable names.
This is just a proposed explanation of this convention, as I've interpreted it - I assumed that the convention came from a language like Haskell, so I tailored it according to that. So beware that I might have misjudged how it is used in the Rust language, or at least how it is used in the Rust tutorial.
People reading the tutorial may not be familiar with the convention of naming lists, vectors and the like as xs, ys, etc. Without some explanation of the reasoning behind it, it might come off as just throwaway non-descriptive names. Languages like Haskell gets flak from using short, non-descriptive names, while in reality, there are clear conventions and reasons for using certain terse variable names.
I assumed that the convention came from a language like Haskell, so I
tailored the explanation according to that.
This generalises the behaviour with struct fields (which recieve no
dead_code warning if they have a leading _), and other similar lints, to
all items, e.g. `fn _foo() {} fn main() {}` has no warnings.
Fixes str/struct ambiguity (by removing the synonym) and pushes raw searches to the history instead of processed ones.
# [Live Version Here](http://cg.scs.carleton.ca/~abeinges/doc/std/)
Reduces time to build stage0 from 11:30 to 9:40 on my machine.
There's a tradeoff here since doing this will make the stage1 compile-fail tests fail.
r? @pcwalton
