| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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.
|
|
Incorporate `dyn` into more comments and docs.
r? @rust-lang/docs
|
|
|
|
|
|
It used to point to the implementation PR.
|
|
|
|
Clarifying documentation for collections::hash_map::Entry::or_insert
Previous version does not show that or_insert does not insert the passed value, as the passed value was the same value as what was already in the map.
|
|
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.
|
|
|
|
|
|
Helps users to understand capacity related values, which may surpise on
Windows.
Also is a step towards clarifying understanding of `OsStr`'s len() return
value.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Increase `Duration` approximate equal threshold to 1us
Previously this threshold when testing was 100ns, but the Windows
documentation states:
> which is a high resolution (<1us) time stamp
which presumably means that we could have up to 1us resolution, which
means that 100ns doesn't capture "equivalent" time intervals due to
various bits of rounding here and there.
It's hoped that this..
Closes #56034
|
|
Replace data.clone() by Arc::clone(&data) in mutex doc.
Arc::clone(&from) is considered as more idiomatic because it conveys more explicitly the meaning of the code.
Since this clone is visible in the official documentation, I thought it could be better to use the more idiomatic version.
|
|
Previously this threshold when testing was 100ns, but the Windows
documentation states:
> which is a high resolution (<1us) time stamp
which presumably means that we could have up to 1us resolution, which
means that 100ns doesn't capture "equivalent" time intervals due to
various bits of rounding here and there.
It's hoped that this..
Closes #56034
|
|
I'm not sure why this is failing, so let's hopefully get some more
information to help investigation!
|
|
Arc::clone(&from) is considered as more idiomatic because it conveys more explicitly the meaning of the code.
|
|
|
|
value
|
|
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 commit 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.
|
|
fix various typos in doc comments
|
|
Unix RwLock: avoid racy access to write_locked
We should only access `write_locked` if we really got the lock.
|
