Use '^' to specify center alignment in format strings.
```
fmt!( "[{:^5s}]", "Hi" ) -> "[ Hi ]"
fmt!( "[{:^5s}]", "H" ) -> "[ H ]"
fmt!( "[{:^5d}]", 1i ) -> "[ 1 ]"
fmt!( "[{:^5d}]", -1i ) -> "[ -1 ]"
fmt!( "[{:^6d}]", 1i ) -> "[ 1 ]"
fmt!( "[{:^6d}]", -1i ) -> "[ -1 ]"
```
If the padding is odd then the padding on the right will be one
character longer than the padding on the left.
Use '^' to specify center alignment in format strings.
fmt!( "[{:^5s}]", "Hi" ) -> "[ Hi ]"
fmt!( "[{:^5s}]", "H" ) -> "[ H ]"
fmt!( "[{:^5d}]", 1i ) -> "[ 1 ]"
fmt!( "[{:^5d}]", -1i ) -> "[ -1 ]"
fmt!( "[{:^6d}]", 1i ) -> "[ 1 ]"
fmt!( "[{:^6d}]", -1i ) -> "[ -1 ]"
If the padding is odd then the padding on the right will be one
character longer than the padding on the left.
Tuples squashed
They were only correct in the simplest case. Some of the optimisations
are certainly possible but should be introduced carefully and only
when the whole pattern codegen infrastructure is in a better shape.
Fixes#16648.
closes#16800
r? @nikomatsakis - I'm not 100% sure this is the right approach, it is kind of ad-hoc. The trouble is we don't have any intrinsic notion of which types are sized and which are not, we only have the Sized bound, so I have nothing to validate the Sized bound against.
Fixes#16597
I'm not 100% sure this is the correct way to handle this - but I wasn't able to find a better way without doing way more refactoring of the code that I was comfortable with. Comments and criticism are appreciated 😄
The tcp-accept-stress, despite the previous modifications, is still deadlocking
on the osx buildbots. When building/testing/running repeatedly locally, it was
discovered that the test would often fail with TcpStream::connect returning the
error `address not available`.
This test opens up quite a large number of sockets, and it looks like by default
osx isn't the speediest at recycling those sockets for further use.
The test has been modified (and verified) to not deadlock in this error case,
and the test is not just officially ignored on OSX (with no FIXME). I believe
that we'll get good coverage of the relevant code on the linux builders, so this
isn't so much of a loss.
At the same time I turned down the stress parameters to hopefully lighten the
socket load on other platforms.
Not sure if this is addressing the root cause or just patching up a symptom. Also not sure if I should be adding a diagnostic code for this.
Fixes#16750Fixes#15812
Enables any macros using `MacExpr` to be treated as patterns when
they produce a literal in the form `ExprLit` (e.g. `stringify!` or `line!`).
Fixes#16876.
The tcp-accept-stress, despite the previous modifications, is still deadlocking
on the osx buildbots. When building/testing/running repeatedly locally, it was
discovered that the test would often fail with TcpStream::connect returning the
error `address not available`.
This test opens up quite a large number of sockets, and it looks like by default
osx isn't the speediest at recycling those sockets for further use.
The test has been modified (and verified) to not deadlock in this error case,
and the test is not just officially ignored on OSX (with no FIXME). I believe
that we'll get good coverage of the relevant code on the linux builders, so this
isn't so much of a loss.
At the same time I turned down the stress parameters to hopefully lighten the
socket load on other platforms.
It was previously asserted that each thread received at least one connection,
but this is not guaranteed to always be the case due to scheduling. This test
also deadlocked on failure due to a lingering reference to the sending half of
the channel, so that reference is now also eagerly dropped so the test can fail
properly if something bad happens.
Closes#16872
It was previously asserted that each thread received at least one connection,
but this is not guaranteed to always be the case due to scheduling. This test
also deadlocked on failure due to a lingering reference to the sending half of
the channel, so that reference is now also eagerly dropped so the test can fail
properly if something bad happens.
Closes#16872
They were only correct in the simplest case. Some of the optimisations
are certainly possible but should be introduced carefully and only
when the whole pattern codegen infrastructure is in a better shape.
Fixes#16648.
Different Identifiers and Names can have identical textual representations, but different internal representations, due to the macro hygiene machinery (syntax contexts and gensyms). This provides a way to see these internals by compiling with `--pretty expanded,hygiene`.
This is useful for debugging & hacking on macros (e.g. diagnosing https://github.com/rust-lang/rust/issues/15750/https://github.com/rust-lang/rust/issues/15962 likely would've been faster with this functionality).
E.g.
```rust
#![feature(macro_rules)]
// minimal junk
#![no_std]
macro_rules! foo {
($x: ident) => { y + $x }
}
fn bar() {
foo!(x)
}
```
```rust
#![feature(macro_rules)]
// minimal junk
#![no_std]
fn bar /* 61#0 */() { y /* 60#2 */ + x /* 58#3 */ }
```
Fixes#12643
> Say!
> I like labelled breaks/continues!
I will use them with a `for` loop.
And I will use with a `loop` loop.
Say! I will use them ANYWHERE!
… _even_ in a `while` loop.
Because they're now supported there.
`--pretty expanded,hygiene` is helpful with debugging macro issues,
since two identifiers/names can be textually the same, but different
internally (resulting in weird "undefined variable" errors).
