Skip to content

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

New issue

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

#

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

Already on GitHub? # to your account

Jump to bottom
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.
Kobzol pushed a commit to Kobzol/rust that referenced this issue Dec 30, 2024
@cramertj
Add instructions to test error code docs (rust-lang#2145)
6911dc4
bors pushed a commit to rust-lang-ci/rust that referenced this issue Jan 2, 2025
@cramertj
Add instructions to test error code docs (rust-lang#2145)
dd819cf
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@jruderman