Skip to content

Added info about Sublime Text's Rust syntax package. #2881

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
wants to merge 1 commit into from

Conversation

mason-stewart
Copy link

No description provided.

@ghost ghost assigned catamorphism Jul 12, 2012
@catamorphism
Copy link
Contributor

Thanks for the prompt re-request! I'll merge it once the tree is open again.

@mason-stewart
Copy link
Author

Awesome, sounds great. Thanks!

@z0w0
Copy link
Contributor

z0w0 commented Jul 13, 2012

If the package is going to be mentioned in the tutorial, I think it's a good idea to have the package actually working. The package was last changed 5 months ago and breaks a lot because of syntax changes.

@mason-stewart
Copy link
Author

Hmmm, I saw that the last commit was some months ago, but I didn't realize that it was broken. Shall we close this PR until the package has addressed changes to the syntax?

@catamorphism
Copy link
Contributor

Okay, closing. Feel free to submit a new pull request once the package is up to date. Thanks!

flip1995 pushed a commit to flip1995/rust that referenced this pull request Apr 7, 2022
Don't lint `cast_ptr_alignment` when used for unaligned reads and writes

fixes rust-lang#2881

Ideally this would trace the usage of the value rather than only looking at the parent expression, but that would require dataflow analysis. e.g.
```rust
let x = ptr as *const u16;
c.read_unaligned(x);
```

Arch specific intrinsic functions need to be checked for ones which could take an unaligned pointer. This can be another PR.

changelog: Don't lint `cast_ptr_alignment` when used for unaligned reads and writes
RalfJung pushed a commit to RalfJung/rust that referenced this pull request Nov 12, 2023
Treat thread-local statics on main thread as static roots for leakage analysis

Miri currently treats allocations as leaked if they're only referenced in thread-local statics. For threads other than the main thread, this is correct, since the thread can terminate before the program does, but references in the main thread's locals should be treated as living for the duration of the program since the thread lives for the duration of the program.

This PR adds thread-local statics and TLS keys as "static roots" for leakage analysis, but does not yet bless the example program from rust-lang#2881. See rust-lang/miri#2881 (comment)

Closes rust-lang#2881
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

Successfully merging this pull request may close these issues.

3 participants