As of RFC 18, struct layout is undefined. Opting into a C-compatible struct
layout is now down with #[repr(C)]. For consistency, specifying a packed
layout is now also down with #[repr(packed)]. Both can be specified.
To fix errors caused by this, just add #[repr(C)] to the structs, and change
#[packed] to #[repr(packed)]
Closes#14309
[breaking-change]
This appears to be a minor typo. This example implies that x is mutable otherwise the compiler would error on the line before the comment implies.
Please let me know if I'm missing something - I'd love to learn what I got wrong!
It's unfortunate that the read+write operands need special treatment in the AST. A separate vec for all expressions is an alternative, but it doesn't play nicely with trans.
Fixes#14936
A few reasons:
* `Nullable` is basically unused, save for one argument in the `glob` function in `liblibc`, so this change likely impacts nobody negatively. The constructors are never used, and I don't foresee people using them. The people implementing the glob functionality don't seem to be reaching for this POSIX `glob` function, so it seems unlikely to be used heavily.
* At the same time, the old name, `Some`, needlessly conflicted with the same re-exported name in the prelude, which impacted everybody who use glob imports with `libc`. Changing it to something else would simplify things greatly for those people.
* `NotNull` seemed like the best option (others included `Just`, `Valid`, etc. which all had somewhat different connotations than what this type was going for (even `Some` doesn't quite seem like the opposite of `Null`)). Other options included removing the type completely and adding a special, `glob`-specific type. This latter approach doesn't seem future-proof.
Overall, I feel like this is a mildly positive change.
This patch allows json to deserialize integers larger than 2^53 without losing precision. It does this by first keeping the integer portion of a number as a `i64`, and only casting it over to a `f64` if we have a decimal or exponent.
For crates `alloc`–`collections`. This is mostly just updating a few function/method descriptions to use the indicative style.
cc #4361; I’ve sort of assumed that the third-person indicative style has been decided on, but I could update this to use the imperative style if that’s preferred, or even update this to remove all function-style-related changes. (I think that standardising on one thing, even if it’s not the ‘best’ option, is still better than having no standard at all.) The indicative style seems to be more common in the Rust standard library at the moment, especially in the newer modules (e.g. `collections::vec`), more popular in the discussion about it, and also more popular amongst other languages (see https://github.com/rust-lang/rust/issues/4361#issuecomment-33470215).
Stop read+write expressions from expanding into two occurences
in the AST. Add a bool to indicate whether an operand in output
position if read+write or not.
Fixes#14936
This incidentally fixes#16589, because it will cause `MatchIndices` to use `NaiveSearcher` instead of `TwoWaySearcher`, but I'm not sure #16589 should be closed until the underlying problem in `TwoWaySearcher` is found.
This was bothering me (and some other people). The macro was necessary in a transient step of my development, but I converged on a design where it was unnecessary, but it didn't really click that that had happened.
This fixes it up.
This implements `Add` and `Sub` for `Timespec`, which enables `Timespec` to be used as a time span. For example:
```rust
let begin = get_time();
// Do some stuff.
let end = get_time();
let delta = end - begin;
println!("Doing stuff took {}.{:09d} seconds.", delta.sec, delta.nsec);
```
This resolves one of the points mentioned in #2153.
