Make `ParseIntError` and `IntErrorKind` fully public
Why would you write nice error types if I can't read them?
# Why
It can be useful to use `match` with errors produced when parsing strings to int. This would be useful for the `.err_match()` function in my [new crate](https://crates.io/crates/read_input).
---
I could also do this for `ParseFloatError` if people think it is a good idea.
I am new around hear so please tell me if I am getting anything wrong.
Try to make top-level Cargo.toml work without __CARGO_TEST_ROOT.
The last failures I noticed before adding the `__CARGO_TEST_ROOT` hack were in `src/test/run-make/thumb-none-{cortex-m,qemu}`, and had to do with the fact that the top-level `Cargo.toml` uses nightly Cargo features.
If that's the only problem, this PR should work, and we can figure out how to unbreak RLS.
`TryFrom<&[T]> for &[T; $N]` (note *reference* to an array) already exists,
but not needing to dereference makes type inference easier
for example when using `u32::from_be_bytes`.
Also add doc examples doing just that.
Implement checked_add_duration for SystemTime
[Original discussion on the rust user forum](https://users.rust-lang.org/t/std-systemtime-misses-a-checked-add-function/21785)
Since `SystemTime` is opaque there is no way to check if the result of an addition will be in bounds. That makes the `Add<Duration>` trait completely unusable with untrusted data. This is a big problem because adding a `Duration` to `UNIX_EPOCH` is the standard way of constructing a `SystemTime` from a unix timestamp.
This PR implements `checked_add_duration(&self, &Duration) -> Option<SystemTime>` for `std::time::SystemTime` and as a prerequisite also for all platform specific time structs. This also led to the refactoring of many `add_duration(&self, &Duration) -> SystemTime` functions to avoid redundancy (they now unwrap the result of `checked_add_duration`).
Some basic unit tests for the newly introduced function were added too.
I wasn't sure which stabilization attribute to add to the newly introduced function, so I just chose `#[stable(feature = "time_checked_add", since = "1.32.0")]` for now to make it compile. Please let me know how I should change it or if I violated any other conventions.
P.S.: I could only test on Linux so far, so I don't necessarily expect it to compile for all platforms.
read_c_str should call the AllocationExtra hooks
I just hope we do not have other methods that bypass `get_bytes`/`get_bytes_mut`... (looking over the file, I could not find any)
r? @oli-obk
Move a flaky process test out of libstd
This test ensures that everything in `env::vars()` is inherited but
that's not actually true because other tests may add env vars after we
spawn the process, causing the test to be flaky! This commit moves the
test to a run-pass test where it can execute in isolation.
Along the way this removes a lot of the platform specificity of the
test, using iteslf to print the environment instead of a foreign process.
Fix BTreeSet and BTreeMap gdb pretty-printers
The BTreeSet and BTreeMap gdb pretty-printers did not take the node
structure into account, and consequently only worked for shallow sets.
This fixes the problem by iterating over child nodes when needed.
This patch avoids the current approach of implementing some of the
value manipulations in debugger-indepdendent code. This was done for
convenience: a type lookup was needed for the first time, and there
currently are no lldb formatters for these types.
Closes#55771
generator fields are not necessarily initialized
Looking at the MIR we generate for generators, I think we deliberately leave fields of the generator uninitialized in ways that would be illegal if this was a normal struct (or rather, one would have to use `MaybeUninit`). Consider [this example](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=417b4a2950421b726dd7b307e9ee3bec):
```rust
#![feature(generators, generator_trait)]
fn main() {
let generator = || {
let mut x = Box::new(5);
{
let y = &mut *x;
*y = 5;
yield *y;
*y = 10;
}
*x
};
let _gen = generator;
}
```
It generates the MIR
```
fn main() -> (){
let mut _0: (); // return place
scope 1 {
scope 3 {
}
scope 4 {
let _2: [generator@src/main.rs:4:21: 13:6 for<'r> {std::boxed::Box<i32>, i32, &'r mut i32, ()}]; // "_gen" in scope 4 at src/main.rs:14:9: 14:13
}
}
scope 2 {
let _1: [generator@src/main.rs:4:21: 13:6 for<'r> {std::boxed::Box<i32>, i32, &'r mut i32, ()}]; // "generator" in scope 2 at src/main.rs:4:9: 4:18
}
bb0: {
StorageLive(_1); // bb0[0]: scope 0 at src/main.rs:4:9: 4:18
(_1.0: u32) = const 0u32; // bb0[1]: scope 0 at src/main.rs:4:21: 13:6
// ty::Const
// + ty: u32
// + val: Scalar(Bits { size: 4, bits: 0 })
// mir::Constant
// + span: src/main.rs:4:21: 13:6
// + ty: u32
// + literal: Const { ty: u32, val: Scalar(Bits { size: 4, bits: 0 }) }
StorageLive(_2); // bb0[2]: scope 1 at src/main.rs:14:9: 14:13
_2 = move _1; // bb0[3]: scope 1 at src/main.rs:14:16: 14:25
drop(_2) -> bb1; // bb0[4]: scope 1 at src/main.rs:15:1: 15:2
}
bb1: {
StorageDead(_2); // bb1[0]: scope 1 at src/main.rs:15:1: 15:2
StorageDead(_1); // bb1[1]: scope 0 at src/main.rs:15:1: 15:2
return; // bb1[2]: scope 0 at src/main.rs:15:2: 15:2
}
}
```
Notice how we only initialize the first field of `_1` (even though it contains a `Box`!), and then assign it to `_2`. This violates the rule "on assignment, all data must satisfy the validity invariant", and hence miri complains about this code.
What this PR effectively does is to change the validity invariant for generators such that it says nothing about the fields of the generator. We behave as if every field of the generator was wrapped in a `MaybeUninit`.
r? @oli-obk
Cc @nikomatsakis @eddyb @cramertj @withoutboats @Zoxc
Encode a custom "producers" section in wasm files
This commit implements WebAssembly/tool-conventions#65 for wasm files
produced by the Rust compiler. This adds a bit of metadata to wasm
modules to indicate that the file's language includes Rust and the
file's "processed-by" tools includes rustc.
The thinking with this section is to eventually have telemetry in
browsers tracking all this.
Check arg/ret sizedness at ExprKind::Path
This PR solves three problems:
- #50940: ICE on casting unsized tuple struct constructors
- Unsized tuple struct constructors were callable in presence of `unsized_locals`.
- https://github.com/rust-lang/rust/issues/48055#issuecomment-437178966: we cannot relax `Sized` bounds on stable functions because of fn ptr casting
These are caused by lack of `Sized`ness checks for arguments/retvals at **reference sites of `FnDef` items** (not call sites of the functions). Therefore we can basically add more `Sized` obligations on typeck. However, adding `Sized` obligations arbitrarily breaks type inference; to prevent that I added a new method `require_type_is_sized_deferred` which doesn't interfere usual type inference.
Clean up and streamline snapshot data structures
These commits clean up the snapshot structures a bit, so they are more consistent with each other and with the `ena` crate.
They also remove the `OpenSnapshot` and `CommittedSnapshot` entries in the undo log, just like I did for the `ena` crate in https://github.com/rust-lang-nursery/ena/pull/14. This PR in combination with that `ena` PR reduces instruction counts by up to 6% on benchmarks.
r? @nikomatsakis. Note that this isn't quite ready for landing, because the `ena` dependency in the first commit needs to be updated once https://github.com/rust-lang-nursery/ena/pull/14 lands. But otherwise it should be good.
They're not strictly necessary, and they result in the `Vec` being
allocated even for the trivial (and common) case where a
`start_snapshot` is immediately followed by a `commit` or `rollback_to`.
The commit also removes a now-unnecessary argument of
`pop_placeholders()`.
They're not strictly necessary, and they result in the `Vec` being
allocated even for the trivial (and common) case where a
`start_snapshot` is immediately followed by a `commit` or `rollback_to`.
