| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
|
|
Reduces the amount of emitted IR. RawVec has similar optimizations
|
|
|
|
|
|
|
|
|
|
|
|
Also stabilizes saturating_int_assign_impl, gh-92354.
And also make pub fns const where the underlying saturating_*
fns became const in the meantime since the Saturating type was
created.
|
|
|
|
Add note that Vec::as_mut_ptr() does not materialize a reference to the internal buffer
See discussion on https://github.com/thomcc/rust-typed-arena/issues/62 and [t-opsem](https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/is.20this.20typed_arena.20code.20sound.20under.20stacked.2Ftree.20borrows.3F)
This method already does the correct thing here, but it is worth guaranteeing that it does so it can be used more freely in unsafe code without having to worry about potential Stacked/Tree Borrows violations. This moves one more unsafe usage pattern from the "very likely sound but technically not fully defined" box into "definitely sound", and currently our surface area of the latter is woefully small.
I'm not sure how best to word this, opening this PR as a way to start discussion.
|
|
That xref contains the actual documentation for what format! does.
It should be very prominent - particularly, more so than the other
links.
|
|
avoid triple-backtrace due to panic-during-cleanup
Supersedes https://github.com/rust-lang/rust/pull/115020
Cc https://github.com/rust-lang/rust/issues/114954
r? ``@Amanieu``
|
|
|
|
Correct and expand documentation of `handle_alloc_error` and `set_alloc_error_hook`.
The primary goal of this change is to remove the false claim that `handle_alloc_error` always aborts; instead, code should be prepared for `handle_alloc_error` to possibly unwind, and be sound under that condition.
I saw other opportunities for improvement, so I have added all the following information:
* `handle_alloc_error` may panic instead of aborting. (Fixes #114898)
* What happens if a hook returns rather than diverging.
* A hook may panic. (This was already demonstrated in an example, but not stated in prose.)
* A hook must be sound to call — it cannot assume that it is only called by the runtime, since its function pointer can be retrieved by safe code.
I've checked these statements against the source code of `alloc` and `std`, but there may be nuances I haven't caught, so a careful review is welcome.
|
|
|
|
|
|
r=workingjubilee
Add `suggestion` for some `#[deprecated]` items
Consider code:
```rust
fn main() {
let _ = ["a", "b"].connect(" ");
}
```
Currently it shows deprecated warning:
```rust
warning: use of deprecated method `std::slice::<impl [T]>::connect`: renamed to join
--> src/main.rs:2:24
|
2 | let _ = ["a", "b"].connect(" ");
| ^^^^^^^
|
= note: `#[warn(deprecated)]` on by default
```
This PR adds `suggestion` for `connect` and some other deprecated items, so the warning will be changed to this:
```rust
warning: use of deprecated method `std::slice::<impl [T]>::connect`: renamed to join
--> src/main.rs:2:24
|
2 | let _ = ["a", "b"].connect(" ");
| ^^^^^^^
|
= note: `#[warn(deprecated)]` on by default
help: replace the use of the deprecated method
|
2 | let _ = ["a", "b"].join(" ");
| ^^^^
```
|
|
|
|
`set_alloc_error_hook`.
Add the following facts:
* `handle_alloc_error` may panic instead of aborting.
* What happens if a hook returns rather than diverging.
* A hook may panic. (This was already demonstrated in an example,
but not stated in prose.)
* A hook must be sound to call — it cannot assume that it is only
called by the runtime, since its function pointer can be retrieved by
safe code.
|
|
|
|
|
|
avoid transmuting Box when we can just cast raw pointers instead
Always better to avoid a transmute, in particular when the layout assumptions it is making are not clearly documented. :)
|
|
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
[nit] Fix a comment typo.
|
|
fix typo: affect -> effect
I just realized I made a silly typo when writing that comment...
|
|
|
|
|
|
|
|
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
Don't panic in ceil_char_boundary
Implementing the alternative mentioned in this comment: https://github.com/rust-lang/rust/issues/93743#issuecomment-1579935853
Since `floor_char_boundary` will always work (rounding down to the length of the string is possible), it feels best for `ceil_char_boundary` to not panic either. However, the semantics of "rounding up" past the length of the string aren't very great, which is why the method originally panicked in these cases.
Taking into account how people are using this method, it feels best to simply return the end of the string in these cases, so that the result is still a valid char boundary.
|
|
|
|
* remove `impl Provider for Error`
* rename `Demand` to `Request`
* update docstrings to focus on the conceptual API provided by `Request`
* move `core::any::{request_ref, request_value}` functions into `core::error`
* move `core::any::tag`, `core::any::Request`, an `core::any::TaggedOption` into `core::error`
* replace `provide_any` feature name w/ `error_generic_member_access`
* move `core::error::request_{ref,value} tests into core::tests::error module
* update unit and doc tests
|
|
|
|
Fix documentation of impl From<Vec<T>> for Rc<[T]>
The example in the documentation of `impl From<Vec<T>> for <Rc<[T]>` is irrelevant (likely was copied from `impl From<Box<T>> for <Rc<T>`). I suggest taking corresponding example from the documentation of `Arc` and replacing `Arc` with `Rc`.
|
|
Avoid using `ptr::Unique` in `LinkedList` code
Addresses a [comment](https://github.com/rust-lang/rust/pull/103093#discussion_r1268506747) by `@RalfJung` about avoiding use of `core::ptr::Unique` in the standard library.
|
|
str.rs: remove "Basic usage" text
Only one example is given
|
|
string.rs: remove "Basic usage" text
Only a single example is given
|
|
Add the attribute to standard library functions that
are guaranteed to never return null pointers, as their
originating data wouldn't allow it.
|
|
It lints against features that are inteded to be internal to the
compiler and standard library. Implements MCP #596.
We allow `internal_features` in the standard library and compiler as those
use many features and this _is_ the standard library from the "internal to the compiler and
standard library" after all.
Marking some features as internal wasn't exactly the most scientific approach, I just marked some
mostly obvious features. While there is a categorization in the macro,
it's not very well upheld (should probably be fixed in another PR).
We always pass `-Ainternal_features` in the testsuite
About 400 UI tests and several other tests use internal features.
Instead of throwing the attribute on each one, just always allow them.
There's nothing wrong with testing internal features^^
|
|
|
|
Only one example is given
|
|
Only a single example is given
|
|
r=Mark-Simulacrum
Improve test case for experimental API remove_matches
## Add Test Cases for `remove_matches` Function
### Motivation
After reading the discussion in [this GitHub thread](https://github.com/rust-lang/rust/pull/71780), I'm trying to redesign the current API to use less memory when working with `String` and to make it simpler. I've discovered that some test cases are very helpful in ensuring that the new API behaves as intended. I'm still in the process of redesigning the current API, and these test cases have proven to be very useful.
### Testing
The current test has been tested with the command `./x test --stage 0 library/alloc`.
### Overview
This pull request adds several new test cases for the `remove_matches` function to make sure it works correctly in different situations. The `remove_matches` function is used to get rid of all instances of a specific pattern from a given text. These test cases thoroughly check how the function behaves in various scenarios.
### Test Cases
1. **Single Pattern Occurrence** (`test_single_pattern_occurrence`):
- Description: Tests the removal of a single pattern occurrence from the text.
- Input: Text: "abc", Pattern: 'b'
- Expected Output: "ac"
2. **Repeat Test Single Pattern Occurrence** (`repeat_test_single_pattern_occurrence`):
- Description: Repeats the previous test case to ensure consecutive removal of the same pattern.
- Input: Text: "ac", Pattern: 'b'
- Expected Output: "ac"
3. **Single Character Pattern** (`test_single_character_pattern`):
- Description: Tests the removal of a single character pattern.
- Input: Text: "abcb", Pattern: 'b'
- Expected Output: "ac"
4. **Pattern with Special Characters** (`test_pattern_with_special_characters`):
- Description: Tests the removal of a pattern containing special characters.
- Input: Text: "ศไทย中华Việt Nam; foobarศ", Pattern: 'ศ'
- Expected Output: "ไทย中华Việt Nam; foobar"
5. **Pattern Empty Text and Pattern** (`test_pattern_empty_text_and_pattern`):
- Description: Tests the removal of an empty pattern from an empty text.
- Input: Text: "", Pattern: ""
- Expected Output: ""
6. **Pattern Empty Text** (`test_pattern_empty_text`):
- Description: Tests the removal of a pattern from an empty text.
- Input: Text: "", Pattern: "something"
- Expected Output: ""
7. **Empty Pattern** (`test_empty_pattern`):
- Description: Tests the behavior of removing an empty pattern from the text.
- Input: Text: "Testing with empty pattern.", Pattern: ""
- Expected Output: "Testing with empty pattern."
8. **Multiple Consecutive Patterns 1** (`test_multiple_consecutive_patterns_1`):
- Description: Tests the removal of multiple consecutive occurrences of a pattern.
- Input: Text: "aaaaa", Pattern: 'a'
- Expected Output: ""
9. **Multiple Consecutive Patterns 2** (`test_multiple_consecutive_patterns_2`):
- Description: Tests the removal of a longer pattern that occurs consecutively.
- Input: Text: "Hello **world****today!**", Pattern: "**"
- Expected Output: "Hello worldtoday!"
10. **Case Insensitive Pattern** (`test_case_insensitive_pattern`):
- Description: Tests the removal of a case-insensitive pattern from the text.
- Input: Text: "CASE ** SeNsItIvE ** PaTtErN.", Pattern: "sEnSiTiVe"
- Expected Output: "CASE ** SeNsItIvE ** PaTtErN."
|
|
Stabilize const-weak-new
This is a fairly uncontroversial library stabilization, so I'm going ahead and proposing it to ride the trains to stable.
This stabilizes the following APIs, which are defined to be non-allocating constructors.
```rust
// alloc::rc
impl<T> Weak<T> {
pub const fn new() -> Weak<T>;
}
// alloc::sync
impl<T> Weak<T> {
pub const fn new() -> Weak<T>;
}
```
Closes #95091
``@rustbot`` modify labels: +needs-fcp
|
|
Bump its stabilization version several times along
the way to accommodate changes in release processes.
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
Co-authored-by: Trevor Gross <t.gross35@gmail.com>
|
|
|
|
Documentation: Fix Stilted Language in Vec->Indexing
Problem
Language in the Vec->Indexing documentation sounds stilted due to incorrect word ordering: "... type allows to access values by index."
Solution
Reorder words in the Vec->Indexing documentation to flow better: "... type allows access to values by index." The phrase "allows access to" also matches other existing documentation.
|
|
Rollup of 3 pull requests
Successful merges:
- #112151 (Clarify behavior of inclusive bounds in BTreeMap::{lower,upper}_bound)
- #113512 (Updated lines doc to include trailing carriage return note)
- #114203 (Effects: don't print `host` param in diagnostics)
r? `@ghost`
`@rustbot` modify labels: rollup
|
