-
Couldn't load subscription status.
- Fork 400
Automatic Rustup #4645
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
Merged
Merged
Automatic Rustup #4645
+19
−1
Conversation
This file contains hidden or 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
… r=the8472,joshtriplett Add `FromIterator` impls for `ascii::Char`s to `String`s Wanted to `collect` ascii chars into a `String` while working on #141369 , and was surprised these impls don't exist. Seems to me to be simply oversight. BTW, I only added `impl FromIterator<ascii::Char> for Cow<'_, str>`, without a corresponding `FromIterator<&Char>` impl, because there's no existing impl for `FromIterator<&char>`, but that might be oversight too. cc #110998
Add NonNull pattern types These are the final piece missing for * rust-lang/rust#136006 We cannot use the previous scheme of using an integer range for raw pointers, as we're not just changing the layout of raw pointers anymore, but also the type representation. And we can't represent "any provenance or NonZero<usize>" natively as patterns. So I created a new `!null` pattern. Since this is all unstable representation stuff for replacing rustc_layout_scalar_range_start with pattern types, the divergence from normal patterns is fine, especially since T-lang seems interested in exploring general negation patterns r? `@BoxyUwU`
…ror, r=nnethercote Code refactoring on hir report_no_match_method_error While working on rust-lang/rust#147753, I found `report_no_match_method_error` now is too long for maintain, 1200 lines of code now: https://github.com/rust-lang/rust/blob/57ef8d642d21965304bde849bab4f389b4353e27/compiler/rustc_hir_typeck/src/method/suggest.rs#L589-L1736 this PR try to refactor it. I tried my best to group most related code into same places, but the logic here is still very complex, there are some variables across different functions, maybe we need more work to make it better understand. Maybe we could add a tidy check to avoid long spaghetti code. r? `@nnethercote`
const Cell methods Tracking: rust-lang/rust#147787 r? `@oli-obk`
Create UTF-8 version of `OsStr`/`OsString` Implement a UTF-8 version of `OsStr`/`OsString`, in addition to the existing bytes and WTF-8 platform-dependent encodings. This is applicable for several platforms, but I've currently only implemented it for Motor OS: - WASI uses Unicode paths, but currently reexports the Unix bytes-assuming `OsStrExt`/`OsStringExt` traits. - [wasi:filesystem](https://wa.dev/wasi:filesystem) APIs: > Paths are passed as interface-type `strings`, meaning they must consist of a sequence of Unicode Scalar Values (USVs). Some filesystems may contain paths which are not accessible by this API. - In [wasi-filesystem#17](WebAssembly/wasi-filesystem#17 (comment)), it was decided that applications can use any Unicode transformation format, so we're free to use UTF-8 (and probably already do). This was chosen over specifically UTF-8 or an ad hoc encoding which preserves paths not representable in UTF-8. > The current API uses strings for filesystem paths, which contains sequences of Unicode scalar values (USVs), which applications can work with using strings encoded in UTF-8, UTF-16, or other Unicode encodings. > > This does mean that the API is unable to open files which do not have well-formed Unicode encodings, which may want separate APIs for handling such paths or may want something like the arf-strings proposal, but if we need that we should file a new issue for it. - As of Redox OS [0.7.0](https://www.redox-os.org/news/release-0.7.0/), "All paths are now required to be UTF-8, and the kernel enforces this". This appears to have been implemented in commit [d331f72f](https://gitlab.redox-os.org/redox-os/kernel/-/commit/d331f72f2a51fa577072f24bc2587829fd87368b) (Use UTF-8 for all paths, 2021-02-14). Redox does not have `OsStrExt`/`OsStringExt`. - Motor OS guarantees that its OS strings are UTF-8 in its [current `OsStrExt`/`OsStringExt` traits](https://github.com/moturus/rust/blob/a828ffcf5f04be5cdd91b5fad608102eabc17ec7/library/std/src/os/motor/ffi.rs), but they're still internally bytes like Unix. This is an alternate approach to rust-lang/rust#147797, which reuses the existing bytes `OsString` and relies on the safety properties of `from_encoded_bytes_unchecked`. Compared to that, this also gains efficiency from propagating the UTF-8 invariant to the whole type, as it never needs to test for UTF-8 validity. Note that Motor OS currently does not build until rust-lang/rust#147930 merges. cc `@tgross35` (for earlier review) cc `@alexcrichton,` `@rylev,` `@loganek` (for WASI) cc `@lasiotus` (for Motor OS) cc `@jackpot51` (for Redox OS)
os_str: Make platform docs more consistent - Port `Buf::as_slice`/`as_mut_slice` wording from wtf8 to bytes - Make `Buf::extend_from_slice_unchecked` docs more platform-independent - wtf8 `Buf` was missing `#[repr(transparent)]`
PassWrapper: Access GlobalValueSummaryInfo::SummaryList via getter for LLVM 22+ llvm/llvm-project#164355 makes SummaryList private and provides a getter method. `@rustbot` label llvm-main
Rollup of 7 pull requests Successful merges: - rust-lang/rust#141445 (Add `FromIterator` impls for `ascii::Char`s to `String`s) - rust-lang/rust#142339 (Add NonNull pattern types) - rust-lang/rust#147768 (Code refactoring on hir report_no_match_method_error) - rust-lang/rust#147788 (const Cell methods) - rust-lang/rust#147932 (Create UTF-8 version of `OsStr`/`OsString`) - rust-lang/rust#147933 (os_str: Make platform docs more consistent) - rust-lang/rust#147948 (PassWrapper: Access GlobalValueSummaryInfo::SummaryList via getter for LLVM 22+) r? `@ghost` `@rustbot` modify labels: rollup
Forbid ShallowInitBox after box deref elaboration. MIR currently contains a `ShallowInitBox` rvalue. Its principal usage is to allow for in-place initialization of boxes. Having it is necessary for drop elaboration to be correct with that in-place initialization. As part of analysis->runtime MIR lowering, we canonicalize deref of boxes to use the stored raw pointer. But we did not perform the same change to the construction of the box. This PR replaces `ShallowInitBox` by the pointer manipulation it represents. Alternatives: - fully remove `ShallowInitBox` and implement `Box` in-place initialization differently; - remove the `ElaborateBoxDeref` pass and keep dereferencing `Box` in runtime MIR.
Update typos I saw that `typos` was a few versions out of date and figured it would be a good idea to update it. Upgrading to `1.38.1` adds the [July](crate-ci/typos#1331), [August](crate-ci/typos#1345), and [September](crate-ci/typos#1370) dictionary updates. As part of this change, I also sorted the configuration file.
refactor: Move to anstream + anstyle for styling `rustc` uses [`termcolor`](https://crates.io/crates/termcolor) for styling and writing, while `annotate-snippets` uses [`anstyle`](https://crates.io/crates/anstyle) for styling and currently writes directly to a `String`. When rendering directly to a terminal, there isn't/shouldn't be any differences. Still, there are differences in the escape sequences, which leads to slightly different output in JSON and SVG tests. As part of my work to have `rustc` use `annotate-snippets`, and to reduce the test differences between the two, I switched `rustc` to use `anstlye` and [`anstream`](https://crates.io/crates/anstream) for styling and writing. The first commit migrates to `anstyle` and `anstream` and notably does not change the output. This is because it includes extra formatting to ensure that `anstyle` + `anstream` match the current output exactly. Most of this code is unnecessary, as it adds redundant resets or uses 256-color (8-bit) when it could be using 4-bit color. The subsequent commits remove this extra formatting while maintaining the correct output when rendered. [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/channel/147480-t-compiler.2Fdiagnostics/topic/annotate-snippets.20hurdles)
Split LTO out of the main codegen coordinator event loop into a separate event loop on the same thread This will make it easier to in the future move all this code to link_binary. Follow up to rust-lang/rust#146209 Part of rust-lang/compiler-team#908
This updates the rust-version file to 6244effd0372d5d88fc859d3bf17ce1efcc2c9ec.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 6244effd0372d5d88fc859d3bf17ce1efcc2c9ec Filtered ref: 2b788f9 Upstream diff: rust-lang/rust@96fe3c3...6244eff This merge was created using https://github.com/rust-lang/josh-sync.
|
Thank you for contributing to Miri! |
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.
Merge ref '6244effd0372' from rust-lang/rust
Pull recent changes from https://github.com/rust-lang/rust via Josh.
Upstream ref: 6244effd0372d5d88fc859d3bf17ce1efcc2c9ec
Filtered ref: 2b788f9
Upstream diff: rust-lang/rust@96fe3c3...6244eff
This merge was created using https://github.com/rust-lang/josh-sync.