Skip to content

nocapture attribute is missing on function arguments #25759

New issue

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

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

Already on GitHub? Sign in to your account

Closed
dotdash opened this issue May 24, 2015 · 6 comments
Closed

nocapture attribute is missing on function arguments #25759

dotdash opened this issue May 24, 2015 · 6 comments
Labels
A-codegen Area: Code generation I-slow Issue: Problems and improvements with respect to performance of generated code. P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@dotdash
Copy link
Contributor

dotdash commented May 24, 2015

In a function like fn foo(x: &i32), the pointer is known not to be captured by the function because its lifetime doesn't allow it. We used to emit the nocapture attribute for such function arguments but don't do so anymore.

@dotdash dotdash added the A-codegen Area: Code generation label May 24, 2015
@dotdash
Copy link
Contributor Author

dotdash commented May 29, 2015

I briefly discussed this with @eddyb on irc the other day, and the way we used to set nocapture would allow for undefined behaviour in safe code:

fn foo(x: &i32) -> *const i32 {
    x as *const i32
}

Since we based the attribute purely on the fact that the pointer has an anonymous lifetime, nocapture would be set here, although the pointer does escape.

I assume we don't want to have UB in safe code, right? That would mean that we need to perform some analysis on the function body to determine which attributes we can emit and that we need to emit those attributes in the metadata, because other crates can't necessarilly perform this analysis, because they don't have access to the function body at all.

@shepmaster
Copy link
Member

What are the benefits of applying the nocapture attribute when it is valid?

@ranma42
Copy link
Contributor

ranma42 commented Dec 27, 2015

LLVM seems to be inferring the nocapture attribute in the functionattrs pass. I think that, thank to lifetimes, the analysis performed in Rust could be more accurate than that performed in LLVM, but for trivial examples LLVM computes the attribute as desired.

@dotdash
Copy link
Contributor Author

dotdash commented Dec 27, 2015

@ranma LLVM can't do that for external functions though. We'd still have to store the information in the crate metadata, even if we don't perform the analysis ourselves and just inspect what LLVM could infer.

@brson brson added I-slow Issue: Problems and improvements with respect to performance of generated code. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 1, 2017
@nikomatsakis
Copy link
Contributor

In the absence of clearer unsafe code guidelines, it is not clear when we should add this attribute anyhow.

@brson brson added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. P-low Low priority and removed A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. labels Jun 1, 2017
@brson
Copy link
Contributor

brson commented Jun 1, 2017

Wishlist. If somebody ever figures it out, great.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-codegen Area: Code generation I-slow Issue: Problems and improvements with respect to performance of generated code. P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants