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

Vectors of resources are logged incorrectly by the shape glue #2614

Closed
msullivan opened this issue Jun 15, 2012 · 1 comment
Closed

Vectors of resources are logged incorrectly by the shape glue #2614

msullivan opened this issue Jun 15, 2012 · 1 comment
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows

Comments

@msullivan
Copy link
Contributor

This program

resource mk(_x: int) { }

fn main() {
    let y = [mk(0), mk(1), mk(2), mk(3), mk(4)];
    log(error, y);
}

produces the following output:

rust: ~[res(0), res(, 1), res(, 2), res(, 3), res(, 4)]
@catamorphism
Copy link
Contributor

No longer an issue; we don't have resources or shape glue, and the equivalent version with structs produces correct output.

RalfJung pushed a commit to RalfJung/rust that referenced this issue Oct 26, 2022
@bors
Auto merge of rust-lang#2614 - saethlin:stack-inspection-tools, r=Ral…
136a1db 
…fJung

Improve miri_print_borrow_stacks

Per post-merge review on rust-lang/miri#2322

* `miri_print_stacks` renamed to `miri_print_borrow_stacks`
* A bit more details in docs, clarified how unstable these functions are meant to be
* Print an `unknown_bottom` if one exists

Open question: Currently `miri_get_alloc_id` gets the expected `AllocId` for `Wildcard` pointers, but for pointers with no provenance, the function reports UB and halts the interpreter. That's definitely wrong. But what _should_ we do? Is it reasonable to check if the pointer has `None` provenance and try to get an `AllocId` for its address? That still leaves us with a failure path, which in this case might be best-handled as an ICE? I'm just not sure that changing the return type of `miri_get_alloc_id` to `Option` is a win because it complicates all normal uses of this.
Aaron1011 pushed a commit to Aaron1011/rust that referenced this issue Jan 6, 2023
@bors
Auto merge of rust-lang#2614 - saethlin:stack-inspection-tools, r=Ral…
3e85970 
…fJung

Improve miri_print_borrow_stacks

Per post-merge review on rust-lang/miri#2322

* `miri_print_stacks` renamed to `miri_print_borrow_stacks`
* A bit more details in docs, clarified how unstable these functions are meant to be
* Print an `unknown_bottom` if one exists

Open question: Currently `miri_get_alloc_id` gets the expected `AllocId` for `Wildcard` pointers, but for pointers with no provenance, the function reports UB and halts the interpreter. That's definitely wrong. But what _should_ we do? Is it reasonable to check if the pointer has `None` provenance and try to get an `AllocId` for its address? That still leaves us with a failure path, which in this case might be best-handled as an ICE? I'm just not sure that changing the return type of `miri_get_alloc_id` to `Option` is a win because it complicates all normal uses of this.
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
@qinheping
Bump CBMC version to 5.88.0 (rust-lang#2614)
a27905f
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@msullivan @catamorphism