Skip to content
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

ICE when using for comprehension against @[] #3381

Closed
JamilH opened this issue Sep 4, 2012 · 2 comments
Closed

ICE when using for comprehension against @[] #3381

JamilH opened this issue Sep 4, 2012 · 2 comments
Labels
A-typesystem Area: The type system I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Milestone

Comments

@JamilH
Copy link

JamilH commented Sep 4, 2012

Here is the code producing internal compiler error

import io::*;

fn main(){
    let name = @["my","name","is","khan"]; 
    for name.each |el| {
        println(el)
    }
}

also issue #2797 needs to be reopened because

fn foo(_x: &[int]) {}
fn main() {
    let x = @[1,2,3];
    foo(x);
}

fails with the same error

╰─$ rustc -v                                                                                                             
rustc 0.3.1
host: x86_64-unknown-linux-gnu
@ghost ghost assigned catamorphism Sep 6, 2012
@catamorphism
Copy link
Contributor

I'll take a look.

@catamorphism
Copy link
Contributor

Both of these examples compile for me. Are you using the latest version of Rust from git, or the released version? If you're using the 0.3.1 release, that's probably why it doesn't work. (If you are using the latest version, comment and I'll reopen.)

flip1995 pushed a commit to flip1995/rust that referenced this issue Jan 27, 2022
Check usages in `ptr_arg`

fixes rust-lang#214
fixes rust-lang#1981
fixes rust-lang#3381
fixes rust-lang#6406
fixes rust-lang#6964

This does not take into account the return type of the function currently, so `(&Vec<_>) -> &Vec<_>` functions may still be false positives.

The name given for the type also has to match the real type name, so `type Foo = Vec<u32>` won't trigger the lint, but `type Vec = Vec<u32>` will. I'm not sure if this is the best way to handle this, or if a note about the actual type should be added instead.

changelog: Check if the argument is used in a way which requires the original type in `ptr_arg`
changelog: Lint mutable references in `ptr_arg`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-typesystem Area: The type system I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Projects
None yet
Development

No branches or pull requests

2 participants