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.

Sign up for GitHub

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

Jump to bottom

LLVM assert "Op types should be identical!" with iter_vec(fail){...} #2145

Closed
jruderman opened this issue Apr 7, 2012 · 1 comment
Closed

LLVM assert "Op types should be identical!" with iter_vec(fail){...} #2145

jruderman opened this issue Apr 7, 2012 · 1 comment

Comments

@jruderman
Copy link
Contributor 

fn iter_vec<T>(v: [T], f: fn(T)) { for v.each {|x| f(x); } }
fn main() { iter_vec(fail) {|i| if i % 2 == 1 { } }; }

rustc fails with:

Assertion failed: (C1->getType() == C2->getType() && "Op types should be identical!"), function getCompare, file /Users/jruderman/code/rust/src/llvm/lib/VMCore/Constants.cpp, line 1705.
@jruderman
Copy link
Contributor Author

Now I get

error: the type of this value must be known in this context

I guess this was fixed along with #2149.

@Bryanskiy Bryanskiy mentioned this issue Aug 24, 2022
Closed
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
@bors
Auto merge of rust-lang#2145 - saethlin:zero-size-creation, r=RalfJung
aa589d3 
Save a created event for zero-size reborrows

Currently, we don't save a created event for zero-sized reborrows. Attempting to use something from a zero-sized reborrow is surprisingly common, for example on `minimal-lexical==0.2.1` we previously just emit this:
```
Undefined Behavior: attempting a write access using <187021> at alloc72933[0x0], but that tag does not exist in the borrow stack for this location
    --> /root/rust/library/core/src/ptr/mod.rs:1287:9
     |
1287 |         copy_nonoverlapping(&src as *const T, dst, 1);
     |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |         |
     |         attempting a write access using <187021> at alloc72933[0x0], but that tag does not exist in the borrow stack for this location
     |         this error occurs as part of an access at alloc72933[0x0..0x8]
     |
     = help: this indicates a potential bug in the program: it performed an invalid operation, but the rules it violated are still experimental
     = help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information

     = note: inside `std::ptr::write::<u64>` at /root/rust/library/core/src/ptr/mod.rs:1287:9
note: inside `minimal_lexical::stackvec::StackVec::push_unchecked` at /root/build/src/stackvec.rs:82:13
    --> /root/build/src/stackvec.rs:82:13
     |
82   |             ptr::write(self.as_mut_ptr().add(self.len()), value);
     |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

... backtrace continues...
```
Which leaves us with the question "where did we make this pointer?" because for every other diagnostic you get a "was created by" note, so I suspect people might be tempted to think there is a Miri bug here. I certainly was.

---
This code duplication is so awful, I'm going to take a look at cleaning it up later. The fact that `ptr_get_alloc_id` can fail in this situation makes things annoying.
@petrochenkov petrochenkov mentioned this issue Jul 24, 2023
Merged
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Apr 8, 2024
@matthiaskrgr
Rollup merge of rust-lang#120144 - petrochenkov:unty, r=davidtwco
337be99 
privacy: Stabilize lint `unnameable_types`

This is the last piece of ["RFC rust-lang#2145: Type privacy and private-in-public lints"](rust-lang#48054).

Having unstable lints is not very useful because you cannot even dogfood them in the compiler/stdlib in this case (rust-lang#113284).
The worst thing that may happen when a lint is removed are some `removed_lints` warnings, but I haven't heard anyone suggesting removing this specific lint.

This lint is allow-by-default and is supposed to be enabled explicitly.
Some false positives are expected, because sometimes unnameable types are a legitimate pattern.
This lint also have some unnecessary false positives, that can be fixed - see rust-lang#120146 and rust-lang#120149.

Closes rust-lang#48054.
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Apr 8, 2024
@rust-timer
Unrolled build for rust-lang#120144
19d700d 
Rollup merge of rust-lang#120144 - petrochenkov:unty, r=davidtwco

privacy: Stabilize lint `unnameable_types`

This is the last piece of ["RFC rust-lang#2145: Type privacy and private-in-public lints"](rust-lang#48054).

Having unstable lints is not very useful because you cannot even dogfood them in the compiler/stdlib in this case (rust-lang#113284).
The worst thing that may happen when a lint is removed are some `removed_lints` warnings, but I haven't heard anyone suggesting removing this specific lint.

This lint is allow-by-default and is supposed to be enabled explicitly.
Some false positives are expected, because sometimes unnameable types are a legitimate pattern.
This lint also have some unnecessary false positives, that can be fixed - see rust-lang#120146 and rust-lang#120149.

Closes rust-lang#48054.
celinval added a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
@celinval
Add --no-fail-fast to compiletest (rust-lang#2145)
3b88c9b 
Compiletest behavior has changed to always failing fast after rust-lang#2045. This PR introduces a --no-fail-fast flag to compiletest which will execute the entire suite regardless of failure.

The regression script uses --no-fail-fast so all failures in a suite are printed as part of the CI.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@jruderman