| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Utilize `?` instead of `return None`.
None
|
|
r=QuietMisdreavus
Document `From` implementations
This PR is solves part of https://github.com/rust-lang/rust/issues/51430. It's my first PR, so I might need some guidance from @skade (as already mentioned in the issue).
The purpose of the PR is to document the `impl From` inside `path.rs` and answering the questions:
- What does it convert?
- Does it allocate memory?
- How expensive are the allocations?
I gave it a first shot, though an experienced rust developer might want to look over it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
make the C part of compiler-builtins opt-out
I'd like to be able to use Xargo to build a libstd without having a full C toolchain for the target. This is a start (but the fact that libstd is a dylib is still a problem).
However, compiler_builtin already has somewhat similar logic to not require a C compiler for wasm:
https://github.com/rust-lang-nursery/compiler-builtins/blob/fe74674f6e4be76d47b66f67d529ebf4186f4eb1/build.rs#L36-L41
(WTF GitHub, why doesn't this show an embedded code preview??)
I wonder if there is a way to not have two separate mechanisms? Like, move the above wasm logic to some place that controls the libstd feature, or so? Or is it okay to have these two mechanisms co-exist?
Cc @alexcrichton
|
|
Update issue number of `shrink_to` methods to point the tracking issue
Tracking issue: #56431
|
|
Remove some uses of try!
|
|
Stabilize dbg!(...)
Per FCP in https://github.com/rust-lang/rust/issues/54306 (which is ~1 day from completion).
r? @SimonSapin
The PR is fairly isolated so a rollup should probably work.
|
|
[std] Osstr len clarity
|
|
Deal with EINTR in net timeout tests
We've seen sporadic QE failures in the timeout tests on this assertion:
assert!(kind == ErrorKind::WouldBlock || kind == ErrorKind::TimedOut);
So there's an error, but not either of the expected kinds. Adding a
format to show the kind revealed `ErrorKind::Interrupted` (`EINTR`).
For the cases that were using `read`, we can just use `read_exact` to
keep trying after interruption. For those using `recv_from`, we have to
manually loop until we get a non-interrupted result.
|
|
use MaybeUninit instead of mem::uninitialized for Windows Mutex
I hope this builds, I do not have a Windows machine to test...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We've seen sporadic QE failures in the timeout tests on this assertion:
assert!(kind == ErrorKind::WouldBlock || kind == ErrorKind::TimedOut);
So there's an error, but not either of the expected kinds. Adding a
format to show the kind revealed `ErrorKind::Interrupted` (`EINTR`).
For the cases that were using `read`, we can just use `read_exact` to
keep trying after interruption. For those using `recv_from`, we have to
manually loop until we get a non-interrupted result.
|
|
Use raw_entry for more efficient interning
Fixes https://github.com/rust-lang/rust/issues/56308#issuecomment-442492744
|
|
Add libstd Cargo feature "panic_immediate_abort"
It stop asserts and panics from libstd to automatically
include string output and formatting code.
Use case: developing static executables smaller than 50 kilobytes,
where usual formatting code is excessive while keeping debuggability
in debug mode.
May resolve #54981.
|
|
|
|
|
|
|
|
Removed unneeded refactoring of read_one_byte, which removed the unneeded dynamic dispatch (`dyn Read`) used by that function.
|
|
|
|
|
|
It stop asserts and panics from libstd to automatically
include string output and formatting code.
Use case: developing static executables smaller than 50 kilobytes,
where usual formatting code is excessive while keeping debuggability
in debug mode.
May resolve #54981.
|
|
libcore: Add VaList and variadic arg handling intrinsics
## Summary
- Add intrinsics for `va_start`, `va_end`, `va_copy`, and `va_arg`.
- Add `core::va_list::VaList` to `libcore`.
Part 1 of (at least) 3 for #44930
Comments and critiques are very much welcomed 😄
|
|
fix futures creating aliasing mutable and shared ref
Fixes the problem described in https://github.com/solson/miri/issues/532#issuecomment-442552764: `set_task_waker` takes a shared reference and puts a copy into the TLS (in a `NonNull`), but `get_task_waker` gets it back out as a mutable reference. That violates "mutable references must not alias anything"!
|
|
Fix a typo in the documentation of std::ffi
|
|
Fix small typo in comment of thread::stack_size
|
|
Make std::os::unix/linux::fs::MetadataExt::a/m/ctime* documentation clearer
I was confused by this API so I clarified what they are doing.
I was wondering if I should try to unify more documentation and examples between `unix` and `linux` (e.g. “of the file” is used in `unix` to refer to the file these metadata is for, “of this file” in `linux`, “of the underlying file” in `std::fs::File`).
|
|
Fix small doc mistake on std::io::read::read_to_end
The std::io::read main documentation can lead to error because the buffer is prefilled with 10 zeros that will pad the response.
Using an empty vector is better.
The `read_to_end` documentation is already correct though.
This is my first rust PR, don't hesitate to tell me if I did something wrong.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Add the llvm intrinsics used to manipulate a va_list.
- Add the va_list lang item in order to allow implementing
VaList in libcore.
|
|
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.
|
|
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.
|
