Introduce ElementSwaps and Permutations. ElementSwaps is an iterator
that for a given sequence length yields the element swaps needed
to visit each possible permutation of the sequence in turn.
We use an algorithm that generates a sequence such that each permutation
is only one swap apart.
let mut v = [1, 2, 3];
for perm in v.permutations_iter() {
// yields 1 2 3 | 1 3 2 | 3 1 2 | 3 2 1 | 2 3 1 | 2 1 3
}
The `.permutations_iter()` yields clones of the input vector for each
permutation.
If a copyless traversal is needed, it can be constructed with
`ElementSwaps`:
for (a, b) in ElementSwaps::new(3) {
// yields (2, 1), (1, 0), (2, 1) ...
v.swap(a, b);
// ..
}
The iterator over incoming connections has no natural end, so it should always return Some(_).
Currently, if an incoming connection fails, the iterator returns None.
Trying to accept another connection afterwards enters the realm of undefined behavior (due to the iterator protocol being silent on the issue).
This PR changes wraps the underlying accept call in Some, so the iterator never finishes.
Also redefine all of the standard logging macros to use more rust code instead
of custom LLVM translation code. This makes them a bit easier to understand, but
also more flexibile for future types of logging.
Additionally, this commit removes the LogType language item in preparation for
changing how logging is performed.
Previously, conversion to ints, uints, and BigUints clamped the value
within the range of that datatype. With this commit, conversion
overflows fail the task. To handle overflows gracefully, use the new
to_*_opt() methods.
The trait will keep the `Iterator` naming, but a more concise module
name makes using the free functions less verbose. The module will define
iterables in addition to iterators, as it deals with iteration in
general.
The trait will keep the `Iterator` naming, but a more concise module
name makes using the free functions less verbose. The module will define
iterables in addition to iterators, as it deals with iteration in
general.
The following parses and works as expected with this change:
```rust
'foo: for i in range(0, 10) {
for j in range(0, 10) {
if i + j == 15 { break 'foo; }
}
}
```
This removes another large chunk of this odd 'clownshoes' identifier showing up
in symbol names. These all originated from external crates because the encoded
items were encoded independently of the paths calculated in ast_map. The
encoding of these paths now uses the helper function in ast_map to calculate the
"pretty name" for an impl block.
Unfortunately there is still no information about generics in the symbol name,
but it's certainly vastly better than before
hash::__extensions__::write::_version::v0.8
becomes
hash::Writer$SipState::write::hversion::v0.8
This also fixes bugs in which lots of methods would show up as `meth_XXX`, they
now only show up as `meth` and throw some extra characters onto the version
string.
Here are fixes for more problems mentioned in #8787. I think I've addressed everything mentioned there except for @nikomatsakis's comment about match/patterns now. (This also fixes the bug in struct alignment that @pnkfelix mentioned from my earlier pull request #8872.)
The biggest change here is to make fill-paragraph (M-q) and auto-fill-mode work inside different variations of multi-line and doc comments. Because of the way emacs paragraph fills work (callbacks interacting with global regexp variables that are used in odd ways) there were quite a few edge cases that I had to work around.
The only way I was able to keep it all straight was to create some regression tests. They use the emacs lisp regression testing tool ERT, and are included as the last commit here. I added a few tests for indentation as well. I have not attempted to integrate the tests into the overall rust compiler build process, since I can't imagine anyone would want the compiler build to have a dependency on emacs. Maybe at some point tools like this get their own repositories? Just a thought.
One other thought related to the tests: should there be a place to put these types of style samples that isn't specific to one text editor? Maybe as part of an official rust style guide, but in a form that would allow tools like this to pull out the samples and use them for tests?
This is a patch to fix#6031. I didn't see any tests for the C++ library code, so I didn't write a test for my changes. Did I miss something, or are there really no tests?
