Skip to content

Unify our bytepointer representation in the libraries #1672

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

Closed
marijnh opened this issue Jan 26, 2012 · 2 comments
Closed

Unify our bytepointer representation in the libraries #1672

marijnh opened this issue Jan 26, 2012 · 2 comments

Comments

@marijnh
Copy link
Contributor

marijnh commented Jan 26, 2012

We currently have sbuf, *u8, and *void, which hampers interop somehow. I think sbuf can be thrown out altogether. *void used for 'raw memory holding whichever', and *u8 for stuff that's explicitly a buffer of bytes or characters.

@graydon
Copy link
Contributor

graydon commented Jan 26, 2012

Agreed. Sbuf is vestigial from when we didn't have unsafe pointer types.

@marijnh
Copy link
Contributor Author

marijnh commented Feb 1, 2012

Actually, sbuf is a synonym for *u8 now (I thought it was still a native type). Closing this in favour of #1715.

@marijnh marijnh closed this as completed Feb 1, 2012
celinval added a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
)

Add a new module reachability which implements the reachability algorithm. Add the end to end logic for the reachability starting from all the harnesses in the target crate.

## Resolved issues:

Resolves rust-lang#1672

## Related RFC:

rust-lang#1588

## Call-outs:

    We still need to build the custom sysroot in order to fix the missing functions issue.
    I added a mechanism to run the regression tests using the MIR linker inside compiletest.
    I ran the regression manually (with the mir_linker enabled) the only tests that didn't pass were:
        cargo-kani/asm/global_error/doesnt_call_crate_with_global_asm.expected: The global assembly is out of the scope so it doesn't get processed. If we want to keep that behavior, we will have to inspect all items manually.
        cargo-kani/cargo-tests-dir/expected: This might be a legit issue that I need to fix on kani-driver logic.
        cargo-ui/dry-run/expected: Not an issue (arguments to the compiler changes).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants