Automatic Rustup #4123
Merged
Automatic Rustup #4123
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
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Move some things to `std::sync::poison` and reexport them in `std::sync` Tracking issue: #134646 r? `@tgross35` I've used `sync_poison_mod` feature flag instead, because `sync_poison` had already been used back in 1.2. try-job: x86_64-msvc
Pass objcopy args for stripping on OSX When `-Cstrip` was changed in #131405 to use the bundled rust-objcopy instead of /usr/bin/strip on OSX, strip-like arguments were preserved. But strip and objcopy are, while being the same binary, different, they have different defaults depending on which binary they are. Notably, strip strips everything by default, and objcopy doesn't strip anything by default. Additionally, `-S` actually means `--strip-all`, so debuginfo stripped everything and symbols didn't strip anything. We now correctly pass `--strip-debug` and `--strip-all`. fixes #135028 try-job: aarch64-apple try-job: dist-aarch64-apple
…marked as must-be-overridden
rustc_intrinsic: support functions without body
We synthesize a HIR body `loop {}` but such bodyless intrinsics.
Most of the diff is due to turning `ItemKind::Fn` into a brace (named-field) enum variant, because it carries a `bool`-typed field now. This is to remember whether the function has a body. MIR building panics to avoid ever translating the fake `loop {}` body, and the intrinsic logic uses the lack of a body to implicitly mark that intrinsic as must-be-overridden.
I first tried actually having no body rather than generating the fake body, but there's a *lot* of code that assumes that all function items have HIR and MIR, so this didn't work very well. Then I noticed that even `rustc_intrinsic_must_be_overridden` intrinsics have MIR generated (they are filled with an `Unreachable` terminator) so I guess I am not the first to discover this. ;)
r? `@oli-obk`
Pass the arch rather than full target name to windows_registry::find_tool The full target name can be anything with custom target specs. Passing just the arch wasn't possible before cc 1.2, but is now thanks to rust-lang/cc-rs#1285. try-job: i686-msvc
…zkan bootstrap: correctly handle doc paths within submodules Fixes #135041 by passing the correct submodule path when requiring submodules. This PR changes `is_path_in_submodule` to `submodule_path_of`. `submodule_path_of` returns the path of the containing submodule when given a path nested inside a submodule we handle, and `None` otherwise. I tested this manually locally by unregistering the `src/tools/cargo` submodule, then running `./x doc src/tools/cargo/src/doc`. This command fails on master with ``` thread 'main' panicked at src/bootstrap/src/utils/helpers.rs:441:5: std::fs::read_dir(dir) failed with No such file or directory (os error 2) ``` since the require submodule fails as `src/tools/cargo/src/doc` is not a known submodule. Now we use the submodule path if such a nested-in-submodule-path is passed, and thus running this command with cargo submodule unregistered still succeeds: ``` Rustbook (x86_64-unknown-linux-gnu) - cargo Doc path: /home/joe/repos/rust/build/x86_64-unknown-linux-gnu/doc/cargo/index.html Build completed successfully in 0:00:11 ``` r? `@onur-ozkan`
[Debuginfo] Force enum `DISCR_*` to `static const u64` to allow for inspection via LLDB see [here](https://rust-lang.zulipchat.com/#narrow/channel/317568-t-compiler.2Fwg-debugging/topic/Revamping.20Debuginfo/near/486614878) for more info. This change mainly helps `*-msvc` debugged with LLDB. Currently, LLDB cannot inspect `static` struct fields, so the intended visualization for enums is only borderline functional, and niche enums with ranges of discriminant cannot be determined at all . LLDB *can* inspect `static const` values (though for whatever reason, non-enum/non-u64 consts don't work). This change adds the `LLVMRustDIBuilderCreateQualifiedType` to the rust FFI layer to wrap the discr type with a `const` modifier, as well as forcing all generated integer enum `DISCR_*` values to be u64's. Those values will only ever be used by debugger visualizers anyway, so it shouldn't be a huge deal, but I left a fixme comment for it just in case.. The `tag` also still properly reflects the discriminant type, so no information is lost.
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.
Please close and re-open this PR to trigger CI, then enable auto-merge.