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

Improve error message for deref field on native ptr #11004

Closed
pnkfelix opened this issue Dec 16, 2013 · 4 comments
Closed

Improve error message for deref field on native ptr #11004

pnkfelix opened this issue Dec 16, 2013 · 4 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints

Comments

@pnkfelix
Copy link
Member

On the ~T and &T pointer types, we support auto-deref as necessary, desugaring expressions like a.f to (*a).f, (**a).f, (***a).f, etc.

We do not perform such auto-deref on the native unsafe *T.

That's okay with me; if you are writing unsafe code, it makes some sense that you should have to think more carefully about each level of deference you are performing.

But I think we could do better on the error message you get when you write code that is expecting that sort of auto-deref:

struct A { x: int, y: f64 }

#[cfg(not(works))]
unsafe fn access(n:*A) -> (int, f64) {
    let x : int = n.x;
    let y : f64 = n.y;
    (x, y)
}

#[cfg(works)]
unsafe fn access(n:*A) -> (int, f64) {
    let x : int = (*n).x;
    let y : f64 = (*n).y;
    (x, y)
}

fn main() {
    use std::cast;
    let a :  A = A { x: 3, y: 3.14 };
    let p : &A = &a;
    let (x,y) = unsafe {
        let n : *A = cast::transmute(p);
        access(n)
    };
    println!("x: {}, y: {}", x, y);
}

rustc interaction:

% rustc /tmp/a.rs
/tmp/a.rs:5:18: 5:21 error: attempted access of field `x` on type `*A`, 
                     but no field with that name was found
/tmp/a.rs:5     let x : int = n.x;
                              ^~~
/tmp/a.rs:6:18: 6:21 error: attempted access of field `y` on type `*A`, 
                     but no field with that name was found
/tmp/a.rs:6     let y : f64 = n.y;
                              ^~~
error: aborting due to 2 previous errors
task 'rustc' failed at 'explicit failure', 
  /Users/fklock/Dev/Mozilla/rust.git/src/libsyntax/diagnostic.rs:102
task '<main>' failed at 'explicit failure', 
  /Users/fklock/Dev/Mozilla/rust.git/src/librustc/lib.rs:391

(I'm just thinking something along the lines of an extra sentence that says "note: *A is a native pointer; perhaps you need to deref with (*expr).field)

@steveklabnik
Copy link
Member

This error message is the same, here's an updated sample:

use std::mem;

struct A { x: int, y: f64 }

#[cfg(not(works))]
unsafe fn access(n:*mut A) -> (int, f64) {
    let x : int = n.x;
    let y : f64 = n.y;
    (x, y)
}

#[cfg(works)]
unsafe fn access(n:*mut A) -> (int, f64) {
    let x : int = (*n).x;
    let y : f64 = (*n).y;
    (x, y)
}

fn main() {
    let a :  A = A { x: 3, y: 3.14 };
    let p : &A = &a;
    let (x,y) = unsafe {
        let n : *mut A = mem::transmute(p);
        access(n)
    };
    println!("x: {}, y: {}", x, y);
}

@steveklabnik steveklabnik added the A-diagnostics Area: Messages for errors, warnings, and lints label Jan 23, 2015
@steveklabnik
Copy link
Member

Triage: same error, updated sample:

use std::mem;

struct A { x: i32, y: f64 }

#[cfg(not(works))]
unsafe fn access(n:*mut A) -> (i32, f64) {
    let x : i32 = n.x;
    let y : f64 = n.y;
    (x, y)
}

#[cfg(works)]
unsafe fn access(n:*mut A) -> (i32, f64) {
    let x : i32 = (*n).x;
    let y : f64 = (*n).y;
    (x, y)
}

fn main() {
    let a :  A = A { x: 3, y: 3.14 };
    let p : &A = &a;
    let (x,y) = unsafe {
        let n : *mut A = mem::transmute(p);
        access(n)
    };
    println!("x: {}, y: {}", x, y);
}

@dovreshef
Copy link

Still a problem. Run into this today as well :).
cc @GuillaumeGomez.

@GuillaumeGomez
Copy link
Member

I'll work on it.

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Aug 17, 2016
eddyb added a commit to eddyb/rust that referenced this issue Aug 18, 2016
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 30, 2022
…ubmodule_update, r=jyn514

Avoid bootstrap from updating rls submodule

Our CI performing tests of the `x86_64-fortanix-unknown-sgx` failed with:
```
21:00:53 + ./configure --enable-lld --disable-rpath --set llvm.ninja=false --set rust.verbose-tests=true
21:00:53 + ./x.py test --stage=1 --target=x86_64-fortanix-unknown-sgx library/std --host= --no-doc --exclude src/tools/linkchecker
21:00:53 Building rustbuild
21:00:53     Finished dev [unoptimized] target(s) in 0.11s
21:00:53 Updating submodule src/tools/rls
21:00:54 Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
21:00:54     Updating crates.io index
21:00:55     Updating git repository `[https://github.com/rust-lang/cargo`](https://github.com/rust-lang/cargo%60)
...
21:00:55     Updating git repository `[https://github.com/rust-lang/rust-clippy`](https://github.com/rust-lang/rust-clippy%60)
21:00:56     Updating git repository `[https://github.com/rust-lang/rustfmt`](https://github.com/rust-lang/rustfmt%60)
21:00:56 error: failed to select a version for `libgit2-sys`.
21:00:56     ... required by package `cargo v0.65.0 (https://github.com/rust-lang/cargo?rev=5514f1e0e1b3650ed8a78306198e90b66b292693#5514f1e0)`
21:00:56     ... which satisfies git dependency `cargo` of package `rls v1.41.0 (/home/jenkins/workspace/rust-sgx-ci/rust/src/tools/rls)`
21:00:56 versions that meet the requirements `^0.13.2` are: 0.13.4+1.4.2, 0.13.3+1.4.2, 0.13.2+1.4.2
21:00:56
21:00:56 the package `libgit2-sys` links to the native library `git2`, but it conflicts with a previous package which links to `git2` as well:
21:00:56 package `libgit2-sys v0.14.0+1.5.0`
21:00:56     ... which satisfies dependency `libgit2-sys = "^0.14.0"` of package `cargo v0.66.0 (/home/jenkins/workspace/rust-sgx-ci/rust/src/tools/cargo)`
21:00:56 Only one package in the dependency graph may specify the same links value. This helps ensure that only one copy of a native library is linked in the final binary. Try to adjust your dependencies so that only one package uses the links ='libgit2-sys' value. For more information, see https://doc.rust-lang.org/cargo/reference/resolver.html#links.
21:00:56
21:00:56 failed to select a version for `libgit2-sys` which could resolve this conflict
```
This is related to the version bump of `libgit2-sys` in rust-lang#11004, but the root cause is the RLS is sunset (rust-lang#100863). When the bootstrapper manages the git submodules, the wrong repo commit is checked out. This PR removes rls from the list of rust submodules.
flip1995 pushed a commit to flip1995/rust that referenced this issue Jun 30, 2023
Check if `if` conditions always evaluate to true in `never_loop`

This fixes the example provided in rust-lang#11004, but it shouldn't be closed as this is still an issue on like
```rust
let x = true;
if x { /* etc */ }`
```
This also makes `clippy_utils::consts::constant` handle `ConstBlock` and `DropTemps`.

changelog: [`never_loop`]: Check if `if` conditions always evaluate to true
flip1995 pushed a commit to flip1995/rust that referenced this issue Sep 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints
Projects
None yet
Development

No branches or pull requests

4 participants