-
Notifications
You must be signed in to change notification settings - Fork 354
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
Rustup #3130
Merged
Merged
Rustup #3130
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Updated libc and doc for Vita target Doc changes: - Updated Vita target readme. The recommended approach to build artifacts for the platform now is [cargo-vita](https://crates.io/crates/cargo-vita) which wraps all the convoluted steps previously described in a yaml for `cargo-make` - Updated maintainer list for Vita target. (`@ZetaNumbers` `@pheki` please agree to be added to the list, `@amg98` please let us know if you're still planning on actively maintaining target support) Code changes: - ~Updated libc for rust-lang/libc#3284 and rust-lang/libc#3366~ (Already merged in #116527) - In dupfd changed the flag same as for esp target, there is no CLOEXEC on Vita - Enabled `new_pair` since we've implemented `socketpair` in Vita newlib
Duplicate `~const` bounds with a non-const one in effects desugaring This should unblock #116058. r? `@oli-obk`
document when atomic loads are guaranteed read-only Based on this [discussion in Zulip](https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/Can.20.60Atomic*.3A.3Aload.60.20perform.20a.20write). The values for x86 and x86_64 are complete guesswork on my side, and I have no clue what the values might be for other architectures. I hope we can get the right people to chime in to gather the required information. :) I'll update Miri to respect these rules once we have more data.
Remove `IdFunctor` trait. It's defined in `rustc_data_structures` but is only used in `rustc_type_ir`. The code is shorter and easier to read if we remove this layer of abstraction and just do the things directly where they are needed. r? `@BoxyUwU`
…,workingjubilee Panic when the global allocator tries to register a TLS destructor Using a `RefCell` avoids the undefined behaviour encountered in #116390 and reduces the amount of `unsafe` code in the codebase.
…ubilee Strict provenance unwind 1. Turned many `usize`s in the personality/unwind code that are actually pointers into `*const u8`. 2. Rewrote `read_encoded_pointer` to conform to strict-provenance, along the lines as described by `@eddyb` [in zulip some time ago](https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/strict.20provenance.20in.20dwarf.3A.3Aeh/near/276197290). This should make supporting CHERI in the future easier (but they use a [slightly modified format in the callsite table](https://cheri-compiler-explorer.cl.cam.ac.uk/z/n6GhhW), which requires a CHERI specific modification to `find_eh_action`).
…uviper Add `-Zstack-protector` test for Windows targets Add variants of the `stack-protector-heuristics-effect.rs` test for 32-bit and 64-bit MSVC Windows and update the original test to run on GNU Windows targets. I added two tests instead of trying to modify the original because: - MSVC uses a different function name (`__security_check_cookie` to perform the test rather than doing the test inline and calling `__stack_chk_fail`). - LLVM's stack protection pass doesn't currently support generating checks for [frames with funclet based EH personality](https://github.com/llvm/llvm-project/blob/37fd3c96b917096d8a550038f6e61cdf0fc4174f/llvm/lib/CodeGen/StackProtector.cpp#L103C1-L109C4). - 32-bit Windows uses classic EH while 64-bit Windows uses table-based EH which results in slightly different codegen. [CI run with test passing on {i686,x86_64}-{msvc,mingw}](https://github.com/rust-lang/rust/actions/runs/6275450644/job/17042958375?pr=116037)
Make TCP connect handle EINTR correctly According to the [POSIX](https://pubs.opengroup.org/onlinepubs/009695399/functions/connect.html) standard, if connect() is interrupted by a signal that is caught while blocked waiting to establish a connection, connect() shall fail and set errno to EINTR, but the connection request shall not be aborted, and the connection shall be established asynchronously. When the connection has been established asynchronously, select() and poll() shall indicate that the file descriptor for the socket is ready for writing. The previous implementation differs from the recomendation: in a case of the EINTR we tried to reconnect in a loop and sometimes get EISCONN error (this problem was originally detected on MacOS). 1. More details about the problem in an [article](http://www.madore.org/~david/computers/connect-intr.html). 2. The original [issue](https://git.picodata.io/picodata/picodata/tarantool-module/-/issues/157).
add some comments and some cleanup around Miri intptrcast `@saethlin` maybe this helps a bit?
Only check in a single place if a pass is enabled. Fixes rust-lang/rust#116294
Use v0.0.0 in compiler crates I may be totally off base here, but my understanding is that it's conventional to use v0.0.0 to reflect the unversioned nature of the compiler crates. Fix that for some of the compiler crates that were created recently.
…ler-errors fix(bootstrap) info message show correct path now running `./x setup tools` showed me a note with incorrect path
Rollup of 4 pull requests Successful merges: - #116650 (add some comments and some cleanup around Miri intptrcast) - #116896 (Only check in a single place if a pass is enabled.) - #116906 (Use v0.0.0 in compiler crates) - #116921 (fix(bootstrap) info message show correct path now) r? `@ghost` `@rustbot` modify labels: rollup
@bors r+ |
☀️ Test successful - checks-actions |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.