Rustc pull #2293
Merged
Rustc pull #2293
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
Do not register `Self: AutoTrait` when confirming auto trait (in old solver) Every built-in auto impl for a trait goal like `Ty: Auto` immediately registers another obligation of `Ty: Auto` as one of its nested obligations, leading to us stressing the cycle detection machinery a lot more than we need to. This is because all traits have a `Self: Trait` predicate. To fix this, remove the call to `impl_or_trait_obligations` in `vtable_auto_impl`, since auto traits do not have where clauses. r? lcnr
Add a .bss-like scheme for encoded const allocs This check if all bytes are zero feel like it should be too slow, and instead we should have a flag that we track, but that seems hard. Let's see how this perfs first. Also we can probably stash the "it's all zero actually" flag inside one of the other struct members that's already not using an entire byte. This optimization doesn't fire all that often, so it's possible that by sticking it in the varint length field, this PR actually makes rmeta size worse.
Don't `alloca` just to look at a discriminant Today we're making LLVM do a bunch of extra work when you match on trivial stuff like `Option<bool>` or `ControlFlow<u8>`. This PR changes that so that simple types like `Option<u32>` or `Result<(), Box<Error>>` can stay as `OperandValue::ScalarPair` and we can still read the discriminant from them, rather than needing to write them into memory to have a `PlaceValue` just to get the discriminant out. Fixes #137503
…viper uefi: helpers: Add DevicePathNode abstractions - UEFI device path is a series of nodes layed out in a contiguous memory region. So it makes sense to use Iterator abstraction for modeling DevicePaths - This PR has been split off from #135368 for easier review. The allow dead_code will be removed in #135368 cc `@nicholasbishop`
…heemdev remove must_use from <*const T>::expose_provenance `<*mut T>::expose_provenance` does not have this attribute, and in fact the function is documented to have a side-effect, so there are perfectly legitimate use-cases where the return value would be ignored.
Rustc dev guide subtree update r? `@jieyouxu`
Pass `CI_JOB_DOC_URL` to Docker Fix-up for rust-lang/rust#136911. I always forget to pass new environment variables to Docker images.. 🤦♂️ r? `@marcoieni` try-job: x86_64-fuchsia
Take a break from reviews
Rollup of 9 pull requests Successful merges: - #134720 (Display valid crate types in error message for --crate-type flag) - #137619 (Provide helpful diagnostics for shebang lookalikes) - #138353 (remove must_use from <*const T>::expose_provenance) - #138452 (Remove `RUN_CHECK_WITH_PARALLEL_QUERIES`) - #138469 (remove comment regarding a removed test directive) - #138477 (Deny impls for `BikeshedGuaranteedNoDrop`) - #138485 (Rustc dev guide subtree update) - #138487 (Pass `CI_JOB_DOC_URL` to Docker) - #138495 (Take a break from reviews) r? `@ghost` `@rustbot` modify labels: rollup
Do not suggest using `-Zmacro-backtrace` for builtin macros For macros that are implemented on the compiler, or that are annotated with `rustc_diagnostic_item`, which have arbitrary implementations from the point of view of the user and might as well be intrinsics, we do *not* mention the `-Zmacro-backtrace` flag. This includes `derive`s and standard macros like `panic!` and `format!`. This PR adds a field to every `Span`'s `ExpnData` stating whether it comes from a builtin macro. This is determined by the macro being annotated with either `#[rustc_builtin_macro]` or `#[rustc_diagnostic_item]`. An alternative to using these attributes that already exist for other uses would be to introduce another attribute like `#[rustc_no_backtrace]` to have finer control on which macros are affected (for example, an error within `vec![]` now doesn't mention the backtrace, but one could make the case that it should). Ideally, instead of carrying this information in the `ExpnData` we'd instead try to query the `DefId` of the macro (that is already stored) to see if it is annotated in some way, but we do not have access to the `TyCtxt` from `rustc_errors`. r? `@petrochenkov`
Update sccache to 0.10.0 This time, does it also for Windows and macOS. This unifies the sccache version across all OSes that we use. r? `@ghost` try-job: dist-aarch64-apple try-job: dist-x86_64-apple try-job: dist-x86_64-msvc try-job: dist-x86_64-msvc-alt try-job: dist-i686-msvc try-job: dist-aarch64-msvc try-job: dist-x86_64-linux try-job: dist-x86_64-netbsd
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
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.
…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
jieyouxu
added
S-waiting-on-review
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.
Note that this is a manual rustc-pull because I wanted to check that I can carry out manual workflow this time.