Rustup #4231
Closed
Rustup #4231
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
Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
added some new test to check for result and options opt Apologies for the delay. Finally have some time to get back into contributing. ## Context - Added some tests to show optimization on result and options for 64 and 128 bits - Relevant issue rust-lang/rust#101210 ## Some newb questions from me - [x] My local llvm IR has `nuw` in `result_nop_match_128` etc whereas [godbolt version](https://rust.godbolt.org/z/Td9zoT5zn) doesn't have. So I put optional there, but not sure if it's desirable (maybe I'm not using the compiled llvm in the repo). I ran the test with ```bash ./x test tests/codegen/try_question_mark_nop.rs ``` - [x] Unless I'm reading it wrongly, but `option_nop_match_128` and `option_nop_traits_128` look to be **not** optimized away? Update: Here's the test for future reference ```rust // CHECK-LABEL: `@option_nop_match_128` #[no_mangle] pub fn option_nop_match_128(x: Option<i128>) -> Option<i128> { // CHECK: start: // CHECK-NEXT: %trunc = trunc nuw i128 %0 to i1 // CHECK-NEXT: br i1 %trunc, label %bb3, label %bb4 // CHECK: bb3: // CHECK-NEXT: %2 = getelementptr inbounds {{(nuw )?}}i8, ptr %_0, i64 16 // CHECK-NEXT: store i128 %1, ptr %2, align 16 // CHECK: bb4: // CHECK-NEXT: %storemerge = phi i128 [ 1, %bb3 ], [ 0, %start ] // CHECK-NEXT: store i128 %storemerge, ptr %_0, align 16 // CHECK-NEXT: ret void match x { Some(x) => Some(x), None => None, } } ``` r? `@scottmcm`
Promote ohos targets to tier2 with host tools. ### What does this PR try to resolve? Try to promote the following [[Tier 2 without Host Tools](https://doc.rust-lang.org/rustc/platform-support.html#tier-2-without-host-tools)](https://doc.rust-lang.org/rustc/platform-support.html#tier-2-without-host-tools) targets to [[Tier 2 with Host Tools](https://doc.rust-lang.org/rustc/platform-support.html#tier-2-with-host-tools)](https://doc.rust-lang.org/rustc/platform-support.html#tier-2-with-host-tools): - `aarch64-unknown-linux-ohos` - `armv7-unknown-linux-ohos` - `x86_64-unknown-linux-ohos` ### More Information? see MCP: rust-lang/compiler-team#811 ### Blockage to be solved? - [x] Submit an MCP - [x] Submit code of promote ohos targets - [x] Resolve related dependencies （`measureme`） The modified code of the measureme has been merged （see rust-lang/measureme#238）. [done] The new version will was released (rust-lang/measureme#240). [done]
Add `From<{integer}>` for `f16`/`f128` impls
This PR adds `impl From<{bool,i8,u8}> for f16` and `impl From<{bool,i8,u8,i16,u16,i32,u32}> for f128`.
The `From<{i64,u64}> for f128` impls are left commented out as adding them would allow using `f128` on stable before it is stabilised like in the following example:
```rust
fn f<T: From<u64>>(x: T) -> T { x }
fn main() {
let x = f(1.0); // the type of the literal is inferred to be `f128`
}
```
None of the impls added in this PR have this issue as they are all, at minimum, also implemented by `f64`.
This PR will need a crater run for the `From<{i32,u32}>` impls, as `f64` is no longer the only float type to implement them (similar to the cause of #125198).
cc `@bjoernager`
r? `@tgross35`
Tracking issue: #116909
…al_methods, r=Amanieu Add `*_value` methods to proc_macro lib This is the implementation of rust-lang/libs-team#459. It allows to get the actual value (unescaped) of the different string literals. Part of rust-lang/rust#136652. r? libs-api
Add std support to cygwin target
…plett Stablize anonymous pipe Since #135822 is staled, I create this PR to stablise anonymous pipe Closes #127154 try-job: test-various
std: Mention clone-on-write mutation in Arc<T> Fixes #138322 r? libs
…-obk
Improve upvar analysis for deref of child capture
Two fixes to the heuristic I implemented in #123660. As I noted in the code:
> Luckily, if this function is not correct, then the program is not unsound, since we still borrowck and validate the choices made from this function -- the only side-effect is that the user may receive unnecessary borrowck errors.
This indeed fixes unnecessary borrowck errors.
r? oli-obk
---
The heuristic is only valid if we deref a `&T`, not a `&mut T` or `Box<T>`, so make sure to check the type. This fixes:
```rust
struct Foo { precise: i32 }
fn mut_ref_inside_mut(f: &mut Foo) {
let x: impl AsyncFn() = async move || {
let y = &f.precise;
};
}
```
Since the capture from `f` to `&f.precise` needs to be treated as a lending borrow from the parent coroutine-closure to the child coroutine.
---
The heuristic is also valid if *any* deref projection in the child capture's projections is a `&T`, but we were only looking at the last one. This ensures that this function is considered not to be lending:
```rust
struct Foo { precise: i32 }
fn ref_inside_mut(f: &mut &Foo) {
let x: impl Fn() -> _ = async move || {
let y = &f.precise;
};
}
```
(Specifically, checking that `impl Fn() -> _` is satisfied is exercising that the coroutine is not considered to be lending.)
Update Rust Foundation links in Readme The Rust Foundation links in the Readme are outdated. I'm not sure if this is the best wording to use in place of the media guide, that can be changed if need be.
Document `#![register_tool]` cc rust-lang/rust#66079
Flatten and simplify some control flow 🫓
update change entry for #137147 r? `@RalfJung`
Rollup of 9 pull requests Successful merges: - #136355 (Add `*_value` methods to proc_macro lib) - #137621 (Add std support to cygwin target) - #137793 (Stablize anonymous pipe) - #138341 (std: Mention clone-on-write mutation in Arc<T>) - #138517 (Improve upvar analysis for deref of child capture) - #138584 (Update Rust Foundation links in Readme) - #138586 (Document `#![register_tool]`) - #138590 (Flatten and simplify some control flow 🫓) - #138592 (update change entry for #137147) r? `@ghost` `@rustbot` modify labels: rollup
Stabilize `asm_goto` feature gate Stabilize `asm_goto` feature (tracked by #119364). The issue will remain open and be updated to track `asm_goto_with_outputs`. Reference PR: rust-lang/reference#1693 # Stabilization Report This feature adds a `label <block>` operand type to `asm!`. `<block>` must be a block expression with type unit or never. The address of the block is substituted and the assembly may jump to the block. When block completes the `asm!` block returns and continues execution. The block starts a new safety context and unsafe operations within must have additional `unsafe`s; the effect of `unsafe` that surrounds `asm!` block is cancelled. See rust-lang/rust#119364 (comment) and rust-lang/rust#131544. It's currently forbidden to use `asm_goto` with output operands; that is still unstable under `asm_goto_with_outputs`. Example: ```rust unsafe { asm!( "jmp {}", label { println!("Jumped from asm!"); } ); } ``` Tests: - tests/ui/asm/x86_64/goto.rs - tests/ui/asm/x86_64/goto-block-safe.stderr - tests/ui/asm/x86_64/bad-options.rs - tests/codegen/asm/goto.rs
…cola Denote `ControlFlow` as `#[must_use]` I've repeatedly hit bugs in the compiler due to `ControlFlow` not being marked `#[must_use]`. There seems to be an accepted ACP to make the type `#[must_use]` (rust-lang/libs-team#444), so this PR implements that part of it. Most of the usages in the compiler that trigger this new warning are "root" usages (calling into an API that uses control-flow internally, but for which the callee doesn't really care) and have been suppressed by `let _ = ...`, but I did legitimately find one instance of a missing `?` and one for a never-used `ControlFlow` value in #137448. Presumably this needs an FCP too, so I'm opening this and nominating it for T-libs-api. This PR also touches the tools (incl. rust-analyzer), but if this went into FCP, I'd split those out into separate PRs which can land before this one does. r? libs-api `@rustbot` label: T-libs-api I-libs-api-nominated
mir_build: Avoid some useless work when visiting "primary" bindings While looking over `visit_primary_bindings`, I noticed that it does a bunch of extra work to build up a collection of “user-type projections”, even though 2/3 of its call sites don't even use them. Those callers can get the same result via `thir::Pat::walk_always`. (And it turns out that doing so also avoids creating some redundant user-type entries in MIR for some binding constructs.) I also noticed that even when the user-type projections *are* used, the process of building them ends up eagerly cloning some nested vectors at every recursion step, even in cases where they won't be used because the current subpattern has no bindings. To avoid this, the visit method now assembles a linked list on the stack containing the information that *would* be needed to create projections, and only creates the concrete projections as needed when a primary binding is encountered. Some relevant prior PRs: - #55274 - rust-lang/rust@0bfe184 in #55937 --- There should be no user-visible change in compiler output.
Emit function declarations for functions with `#[linkage="extern_weak"]`
Currently, when declaring an extern weak function in Rust, we use the following syntax:
```rust
unsafe extern "C" {
#[linkage = "extern_weak"]
static FOO: Option<unsafe extern "C" fn() -> ()>;
}
```
This allows runtime-checking the extern weak symbol through the Option.
When emitting LLVM-IR, the Rust compiler currently emits this static as an i8, and a pointer that is initialized with the value of the global i8 and represents the nullabilty e.g.
```
`@FOO` = extern_weak global i8
`@_rust_extern_with_linkage_FOO` = internal global ptr `@FOO`
```
This approach does not work well with CFI, where we need to attach CFI metadata to a concrete function declaration, which was pointed out in rust-lang/rust#115199.
This change switches to emitting a proper function declaration instead of a global i8. This allows CFI to work for extern_weak functions. Example:
```
`@_rust_extern_with_linkage_FOO` = internal global ptr `@FOO`
...
declare !type !61 !type !62 !type !63 !type !64 extern_weak void `@FOO(double)` unnamed_addr rust-lang#6
```
We keep initializing the Rust internal symbol with the function declaration, which preserves the correct behavior for runtime checking the Option.
r? `@rcvalle`
cc `@jakos-sec`
try-job: test-various
Install licenses into `share/doc/rust/licenses` This changes the path from "licences" to "licenses" for consistency across the repo, including the usage directly around this line. This is a US/UK spelling difference, but I believe the US spelling is also more common in open source in general.
…llaumeGomez rustdoc-json: Don't also include `#[deprecated]` in `Item::attrs` Closes #138378 Not sure if this should bump `FORMAT_VERSION` or not. CC `@Enselic` `@LukeMathWalker` `@obi1kenobi` r? `@GuillaumeGomez,` best reviewed commit-by-commit
…piler-errors Avoid double lowering of idents It's easy to double lower idents and spans because they don't change type when lowered. r? `@cjgillot`
…ootstrap.toml, r=onur-ozkan,jieyouxu,kobzol change config.toml to bootstrap.toml Currently, both Bootstrap and Cargo uses same name as their configuration file, which can be confusing. This PR is based on a discussion to rename `config.toml` to `bootstrap.toml` for Bootstrap. Closes: rust-lang/rust#126875. I have split the PR into atomic commits to make it easier to review. Once the changes are finalized, I will squash them. I am particularly concerned about the changes made to modules that are not part of Bootstrap. How should we handle those changes? Should we ping the respective maintainers?
Rollup of 7 pull requests Successful merges: - #133870 (Stabilize `asm_goto` feature gate) - #137449 (Denote `ControlFlow` as `#[must_use]`) - #137465 (mir_build: Avoid some useless work when visiting "primary" bindings) - #138349 (Emit function declarations for functions with `#[linkage="extern_weak"]`) - #138412 (Install licenses into `share/doc/rust/licenses`) - #138577 (rustdoc-json: Don't also include `#[deprecated]` in `Item::attrs`) - #138588 (Avoid double lowering of idents) Failed merges: - #138321 ([bootstrap] Distribute split debuginfo if present) r? `@ghost` `@rustbot` modify labels: rollup
…sleywiser,jieyouxu Mangle rustc_std_internal_symbols functions This reduces the risk of issues when using a staticlib or rust dylib compiled with a different rustc version in a rust program. Currently this will either (in the case of staticlib) cause a linker error due to duplicate symbol definitions, or (in the case of rust dylibs) cause rustc_std_internal_symbols functions to be silently overridden. As rust gets more commonly used inside the implementation of libraries consumed with a C interface (like Spidermonkey, Ruby YJIT (curently has to do partial linking of all rust code to hide all symbols not part of the C api), the Rusticl OpenCL implementation in mesa) this is becoming much more of an issue. With this PR the only symbols remaining with an unmangled name are rust_eh_personality (LLVM doesn't allow renaming it) and `__rust_no_alloc_shim_is_unstable`. Helps mitigate rust-lang/rust#104707 try-job: aarch64-gnu-debug try-job: aarch64-apple try-job: x86_64-apple-1 try-job: x86_64-mingw-1 try-job: i686-mingw-1 try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: test-various try-job: armhf-gnu
|
☔ The latest upstream changes (possibly 641b8a5) made this pull request unmergeable. Please resolve the merge conflicts. |
rustbot
added
the
S-waiting-on-author
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.