Skip to content

std: Fix perf of local allocations in newsched - #8415

Closed
brson wants to merge 1 commit into
rust-lang:masterfrom
brson:newrt-local-heap-perf
Closed

std: Fix perf of local allocations in newsched#8415
brson wants to merge 1 commit into
rust-lang:masterfrom
brson:newrt-local-heap-perf

Conversation

@brson

@brson brson commented Aug 9, 2013

Copy link
Copy Markdown
Contributor

Mostly optimizing TLS accesses to bring local heap allocation performance
closer to that of oldsched. It's not completely at parity but removing the
branches involved in supporting oldsched and optimizing pthread_get/setspecific
to instead use our dedicated TCB slot will probably make up for it.

Mostly optimizing TLS accesses to bring local heap allocation performance
closer to that of oldsched. It's not completely at parity but removing the
branches involved in supporting oldsched and optimizing pthread_get/setspecific
to instead use our dedicated TCB slot will probably make up for it.
bors added a commit that referenced this pull request Aug 9, 2013
Mostly optimizing TLS accesses to bring local heap allocation performance
closer to that of oldsched. It's not completely at parity but removing the
branches involved in supporting oldsched and optimizing pthread_get/setspecific
to instead use our dedicated TCB slot will probably make up for it.
@bors bors closed this Aug 9, 2013
flip1995 pushed a commit to flip1995/rust that referenced this pull request Feb 24, 2022
Document `pub` requirement for `new_without_default` lint

fixes rust-lang#8415

Also adds some UI tests that ensure that `pub` is required on both the struct _and_ the field. The only thing I'm not sure about is that the lint actually [checks](https://github.com/rust-lang/rust-clippy/blob/master/clippy_lints/src/new_without_default.rs#L102) if `new` is _reachable_, not _public_. To the best of my understanding, both the struct and the method need to be public for the method to be reachable for external crates (I certainly didn't manage to craft a counterexample).

changelog: Document `pub` requirement for ``[`new_without_default`]`` lint.
U007D pushed a commit to U007D/rust-mos that referenced this pull request Aug 21, 2026
8415: Fix faulty assertion when extracting function with macro call r=matklad a=brandondong

**Reproduction:**
```rust
fn main() {
    let n = 1;
    let k = n * n;
    dbg!(n);
}
```
1. Select the second and third lines of the main function. Use the "Extract into function" code assist.
2. Panic occurs in debug, error is logged in release: "[ERROR ide_assists::handlers::extract_function] assertion failed: matches!(path, ast :: Expr :: PathExpr(_))".
3. Function generates successfully on release where the panic was bypassed.
```rust
fn fun_name(n: i32) {
    let k = n * n;
    dbg!(n);
}
```

**Cause:**
- The generated function will take `n` as a parameter. The extraction logic needs to search the usages of `n` to determine whether it is used mutably or not. The helper `path_element_of_reference` is called for each usage but the second usage is a macro call and fails the `Expr::PathExpr(_)` match assertion.
- The caller of `path_element_of_reference` does implicitly assume it to be a `Expr::PathExpr(_)` in how it looks at its parent node for determining whether it is used mutably. This logic will not work for macros.
- I'm not sure if there are any other cases besides macros where it could be something other than a `Expr::PathExpr(_)`. I tried various examples and could not find any.

**Fix:**
- Update assertion to include the macro case.
- Add a FIXME to properly handle checking if a macro usage requires mutable access. For now, return false instead of running the existing logic that is tailored for `Expr::PathExpr(_)`'s.

Co-authored-by: Brandon <brandondong604@hotmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants