Add ASCII fast-path for `char::is_grapheme_extended`
I discovered that `impl Debug for str` is quite slow because it ends up doing a `unicode_data::grapheme_extend::lookup` for each char, which ends up doing a binary search.
This introduces a fast-path for ASCII chars which do not have this property.
The `lookup` is thus completely gone from profiles.
---
As a followup, maybe it’s worth implementing this fast path directly in `unicode_data` so that it can check for the lower bound directly before going to a potentially expensive binary search.
perf: improve write_fmt to handle simple strings
In case format string has no arguments, simplify its implementation with a direct call to `output.write_str(value)`. This builds on `@dtolnay` original [suggestion](https://github.com/serde-rs/serde/pull/2697#issuecomment-1940376414). This does not change any expectations because the original `fn write()` implementation calls `write_str` for parts of the format string.
```rust
write!(f, "text") -> f.write_str("text")
```
```diff
/// [`write!`]: crate::write!
+#[inline]
#[stable(feature = "rust1", since = "1.0.0")]
pub fn write(output: &mut dyn Write, args: Arguments<'_>) -> Result {
+ if let Some(s) = args.as_str() { output.write_str(s) } else { write_internal(output, args) }
+}
+
+/// Actual implementation of the [`write`], but without the simple string optimization.
+fn write_internal(output: &mut dyn Write, args: Arguments<'_>) -> Result {
let mut formatter = Formatter::new(output);
let mut idx = 0;
```
* Hopefully it will improve the simple case for the https://github.com/rust-lang/rust/issues/99012
* Another related (original?) issues #10761
* Previous similar attempt to fix it by by `@Kobzol` #100700
CC: `@m-ou-se` as probably the biggest expert in everything `format!`
Add a new `wasm32-wasip1` target to rustc
This commit adds a new target called `wasm32-wasip1` to rustc. This new target is explained in these two MCPs:
* https://github.com/rust-lang/compiler-team/issues/607
* https://github.com/rust-lang/compiler-team/issues/695
In short, the previous `wasm32-wasi` target is going to be renamed to `wasm32-wasip1` to better live alongside the [new `wasm32-wasip2` target](https://github.com/rust-lang/rust/pull/119616). This new target is added alongside the `wasm32-wasi` target and has the exact same definition as the previous target. This PR is effectively a rename of `wasm32-wasi` to `wasm32-wasip1`. Note, however, that as explained in rust-lang/compiler-team#695 the previous `wasm32-wasi` target is not being removed at this time. This change will reach stable Rust before even a warning about the rename will be printed. At this time this change is just the start where a new target is introduced and users can start migrating if they support only Nightly for example.
test: enable `unpacked-lto` tests
This enables the correct `unpacked-lto` tests.
Not sure whether `.o` should be removed.
They are bitcode for linker-plugin-lto, though there might be some `.o` for `#[no_builtins]`?
Delete architecture-specific memchr code in std::sys
Currently all architecture-specific memchr code is only used in `std::io`. Most of the actual `memchr` capacity exposed to the user through the slice API is instead implemented in `core::slice::memchr`.
Hence this commit deletes `memchr` from `std::sys[_common]` and replace calls to it by calls to `core::slice::memchr` functions. This deletes `(r)memchr` from the list of symbols linked to libc.
The interest of putting architecture specific code back in core is linked to the discussion to be had in #113654
Export `SemanticsImpl` from `ra_ap_hir` crate, since it's already exposed via `Semantics.deref()`
The `SemanticsImpl` type is already de-facto exposed via `<Semantics as Deref>::Target`.
By not being part of the public crate interface it however doesn't get included in the documentation, resulting in a massive blind spot when it comes to `ra_ap_hir`'s type resolution APIs.
Add public function for resolving callable AST exprs to their HIR equivalents
(the PR is motivated by an outside use of the `ra_ap_hir` crate that would benefit from being able to walk a `hir::Function`'s AST, resolving callable exprs within to their HIR equivalents)
Derive `PartialEq`, `Eq` & `Hash` for `hir::Param`
Since `hir::SelfParam`, as well as all members of `hir::Param` already implement `PartialEq`, `Eq` & `Hash` it seems reasonable to also make `hir::Param` implement those.
(the change is motivated by an outside use of the `ra_ap_hir` crate that would benefit from being able to collect params in a `HashSet`)
feature: Add `destructure_struct_binding`
Adds an assist for destructuring a struct in a binding (#8673). I saw that #13997 has been abandoned for a while, so I thought I'd give it a go.
## Example
```rust
let foo = Foo { bar: 1, baz: 2 };
let bar2 = foo.bar;
let baz2 = foo.baz;
let foo2 = foo;
let fizz = Fizz(1, 2);
let buzz = fizz.0;
```
becomes
```rust
let Foo { bar, baz } = Foo { bar: 1, baz: 2 };
let bar2 = bar;
let baz2 = baz;
let foo2 = todo!();
let Fizz(_0, _1) = Fizz(1, 2);
let buzz = _0;
```
More examples in the tests.
## What is included?
- [x] Destructure record, tuple, and unit struct bindings
- [x] Edit field usages
- [x] Non-exhaustive structs in foreign crates and private fields get hidden behind `..`
- [x] Nested bindings
- [x] Carry over `mut` and `ref mut` in nested bindings to fields, i.e. `let Foo { ref mut bar } = ...` becomes `let Foo { bar: Bar { baz: ref mut baz } } = ...`
- [x] Attempt to resolve collisions with other names in the scope
- [x] If the binding is to a reference, field usages are dereferenced if required
- [x] Use shorthand notation if possible
## Known limitations
- `let foo = Foo { bar: 1 }; foo;` currently results in `let Foo { bar } = Foo { bar: 1 }; todo!();` instead of reassembling the struct. This requires user intervention.
- Unused fields are not currently omitted. I thought that this is more ergonomic, as there already is a quick fix action for adding `: _` to unused field patterns.
fix: Goto definition for `index_mut`
Mostly same with #16696.
0ac05c0527/crates/hir-ty/src/infer/mutability.rs (L103-L133)
Thankfully, we are doing similar method resolutions so we can use them like the mentioned PR.
As there are only three `LangItem`s having `Mut` in there names; `FnMut`, `DerefMut` and `IndexMut`, I think that this is the last one 😄
Separate into create and apply edit
Rename usages
Hacky name map
Add more tests
Handle non-exhaustive
Add some more TODOs
Private fields
Use todo
Nesting
Improve rest token generation
Cleanup
Doc -> regular comment
Support mut
Add `to_path_buf()` method for `RelPath`
There seems to be no ergonomic way to obtain a `RelPathBuf` from a corresponding `&RelPath` at the moment, making the latter sort of a dead end.
The `AbsPath` type provides the following:
```rust
impl AbsPath {
// ...
/// Equivalent of [`Path::to_path_buf`] for `AbsPath`.
pub fn to_path_buf(&self) -> AbsPathBuf {
AbsPathBuf::try_from(self.0.to_path_buf()).unwrap()
}
// ...
}
```
So I took the liberty of adding a corresponding equivalent for `RelPath:
```rust
impl RelPath {
// ...
/// Equivalent of [`Path::to_path_buf`] for `RelPath`.
pub fn to_path_buf(&self) -> RelPathBuf {
RelPathBuf::try_from(self.0.to_path_buf()).unwrap()
}
// ...
}
```
(the change is motivated by an outside use of the `ra_ap_paths` crate that would benefit from being able to use `RelPath` and `AbsPath` over `Path`)
os::net: expanding TcpStreamExt for Linux with `tcp_deferaccept`.
allows for socket to process only when there is data to process, the option sets a number of seconds until the data is ready.
