Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Provide region checker hooks for more efficient generic code #15904

Closed
kmcallister opened this issue Jul 22, 2014 · 1 comment
Closed

Provide region checker hooks for more efficient generic code #15904

kmcallister opened this issue Jul 22, 2014 · 1 comment
Labels
E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot.

Comments

@kmcallister
Copy link
Contributor

As an example, consider Clone for Rc<T>. We can elide the refcount bump if the region checker can prove that the new Rc<T> won't outlive the old one. This is somewhat like passing &Rc<T> instead of Rc<T>.

LLVM can probably catch some of these, but we can surely do more if Rc<T> opts in to different semantics. I can imagine writing code like

impl<T> Clone for Rc<T> {
    #[inline]
    fn clone<'a>(&'a self) -> Rc<T> {
        let new = Rc { _ptr: self._ptr, ... }
        if can_outlive!(new, 'a) {
            self.inc_strong();
        }
        new
    }
}

Here can_outlive!() is a deeply magical builtin, on the order of GCC's __builtin_types_compatible_p or __builtin_constant_p. Then suppose I do something like

fn f(x: Rc<uint>) { ... }

fn g() {
    let x = Rc::new(0u);
    f(x.clone());
}

and the clone call gets inlined. The region checker will notice that the argument to f can't outlive x, and will arrange for that can_outlive!(new, 'a) to act like a constant false. (When it can't prove this it becomes true, naturally.)

We'd also need to change Drop for Rc<T>, of course. You can't always statically pair up the clone and drop calls, so I imagine stealing a pointer tag bit to indicate to drop whether it needs to dec_strong. This makes it a dubious win for Rc<T>, but it could help a lot with Arc<T> where you're avoiding atomic memory operations.

I expect this to be particularly useful in generic code. For example the html5ever tree builder has a type parameter for "handle to node", and clones these handles all over the place. When instantiating the tree builder for a refcounted DOM, many of those clones could be elided.

cc @nikomatsakis

@kmcallister kmcallister added A-an-interesting-project E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot. and removed I-wishlist labels Sep 27, 2014
@steveklabnik
Copy link
Member

I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.

This issue has been moved to the RFCs repo: rust-lang/rfcs#645

bors added a commit to rust-lang-ci/rust that referenced this issue Nov 16, 2023
…vscode-version-to-1.78, r=lnicola

editor/code: bump minimum version of VS Code to 1.78

Undoes rust-lang/rust-analyzer#15333.
lnicola pushed a commit to lnicola/rust that referenced this issue Nov 12, 2024
It's been a year since we last bumped this (see rust-lang#15904), and VS Code
1.83 is the first version that supports LSP 3.17.5 (via
vscode-languageclient 9.0.1).

https://code.visualstudio.com/updates/v1_83#_language-server-protocol
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot.
Projects
None yet
Development

No branches or pull requests

2 participants