This feature is partially stabilized, so describe each part in the appropriate place.
r? @alexcrichton @brson
It would be nice to backport this to beta, since this is the first release where this is true. I try really hard to not do doc backports, but this isn't very large, and might be worth making an exception, I dunno.
stalled rather than keeping this annoying mark; I checked that the
original compile-time regression that the mark was intended to
fix (https://github.com/rust-lang/rust/issues/18208) was still
reasonable, but I've not done exhaustive measurements to see how
important this "optimization" really is anymore
Given this code:
fn main() {
let _ = 'abcd';
}
The compiler would give a message like:
error: character literal may only contain one codepoint: ';
let _ = 'abcd';
^~
With this change, the message now displays:
error: character literal may only contain one codepoint: 'abcd'
let _ = 'abcd'
^~~~~~
Fixes#30033
Minimal fix for https://github.com/rust-lang/rust/issues/30563
This covers all the public structs I think; except for Iter and
IntoIter, which I don't know if or how they should be handled.
Use arena allocation instead of reference counting for `Module`s to fix memory leaks from `Rc` cycles.
A module references its module children and its import resolutions, and an import resolution references the module defining the imported name, so there is a cycle whenever a module imports something from an ancestor module.
For example,
```rust
mod foo { // `foo` references `bar`.
fn baz() {}
mod bar { // `bar` references the import.
use foo::baz; // The import references `foo`.
}
}
```
In 8d90d3f368 `BufStream`, the only
consumer of `InternalBufWriter`, was removed. As implied by the name,
this type is private, hence it is currently dead code.
The following PR updates libc version to latest commits for correctly support openbsd.
It corrects several points in rustc to be compatible with libc changes.
r? @alexcrichton
Put back alloca zeroing for issues #29092, #30018, #30530; inject zeroing for #30822.
----
Background context: `fn alloca_zeroed` was removed in PR #22969, so we haven't been "zero'ing" (\*) the alloca's since at least that point, but the logic behind that PR seems sound, so its not entirely obvious how *long* the underlying bug has actually been present. In other words, I have not yet done a survey to see when the new `alloc_ty` and `lvalue_scratch_datum` calls were introduced that should have had "zero'ing" the alloca's.
----
I first fixed#30018, then decided to do a survey of `alloc_ty` calls to see if they needed similar treatment, which quickly led to a rediscovery of #30530.
While making the regression test for the latter, I discovered #30822, which is a slightly different bug (in terms of where the "zero'ing" needs to go), but still relevant.
I haven't finished the aforementioned survey of `fn alloc_ty` calls, but I decided I wanted to get this up for review in its current state (namely to see if my attempt to force developers to include a justification for passing `Uninit` can possibly fly, or if I should abandon that path of action).
----
(*): I am putting quotation marks around "zero'ing" because we no longer use zero as our "dropped" marker value.
Fix#29092Fix#30018Fix#30530Fix#30822
This adds the ability to override the default OOM behavior by setting a handler function. This is used by libstd to print a message when running out of memory instead of crashing with an obscure "illegal hardware instruction" error (at least on Linux).
Fixes#14674
This commit migrates all of the methods on `num::wrapping::OverflowingOps` onto
inherent methods of the integer types. This also fills out some missing gaps in
the saturating and checked departments such as:
* `saturating_mul`
* `checked_{neg,rem,shl,shr}`
This is done in preparation for stabilization,
cc #27755
