-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Labels
A-diagnostics
Area: Messages for errors, warnings, and lints
Comments
This error message is the same, here's an updated sample:
|
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);
} |
Still a problem. Run into this today as well :). |
I'll work on it. |
Merged
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
…ndturner Fixes issue rust-lang#11004 Fixes rust-lang#11004. r? @jonathandturner
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
On the
~T
and&T
pointer types, we support auto-deref as necessary, desugaring expressions likea.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:
rustc interaction:
(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
)The text was updated successfully, but these errors were encountered: