- 08 8月, 2023 25 次提交
-
-
由 bors 提交于
simplify handling of valtrees for unsized types
-
由 bors 提交于
rustc_interface: Dismantle `register_plugins` query It did three independent things: - Constructed `LintStore` - Prepared incremental directories and dep graph - Initialized some fields in `Session` The `LintStore` construction (now `passes::create_lint_store`) is more or less left in place. The incremental stuff is now moved into `fn dep_graph_future`. This helps us to start loading the dep graph a bit earlier. The `Session` field initialization is moved to tcx construction point. Now that tcx is constructed early these fields don't even need to live in `Session`, they can live in tcx instead and be initialized at its creation (see the FIXME). Three previously existing `rustc_interface` queries are de-querified (`register_plugins`, `dep_graph_future`, `dep_graph`) because they are only used locally in `fn global_ctxt` and their results don't need to be saved elsewhere. On the other hand, `crate_types` and `stable_crate_id` are querified. They are used from different places and their use is very similar to the existing `crate_name` query in this regard.
-
由 bors 提交于
Rollup of 7 pull requests Successful merges: - #114376 (Avoid exporting __rust_alloc_error_handler_should_panic more than once.) - #114413 (Warn when #[macro_export] is applied on decl macros) - #114497 (Revert #98333 "Re-enable atomic loads and stores for all RISC-V targets") - #114500 (Remove arm crypto target feature) - #114566 (Store the laziness of type aliases in their `DefKind`) - #114594 (Structurally normalize weak and inherent in new solver) - #114596 (Rename method in `opt-dist`) r? `@ghost` `@rustbot` modify labels: rollup
-
由 Matthias Krüger 提交于
Rename method in `opt-dist` This makes it clearer that the LLVM is the host one (it doesn't necessarily have to be downloaded). On Linux, it comes from the Dockerfile, on Windows it's downloaded. Suggested here: https://github.com/rust-lang/rust/pull/114344#discussion_r1285596217 r? `@lqd`
-
由 Matthias Krüger 提交于
Structurally normalize weak and inherent in new solver It seems pretty obvious to me that we should be normalizing weak and inherent aliases too, since they can always be normalized. This PR still leaves open the question of what to do with opaques, though
💀 **Also**, we need to structurally resolve the target of a coercion, for the UI test to work. r? `@lcnr` -
由 Matthias Krüger 提交于
Store the laziness of type aliases in their `DefKind` Previously, we would treat paths referring to type aliases as *lazy* type aliases if the current crate had lazy type aliases enabled independently of whether the crate which the alias was defined in had the feature enabled or not. With this PR, the laziness of a type alias depends on the crate it is defined in. This generally makes more sense to me especially if / once lazy type aliases become the default in a new edition and we need to think about *edition interoperability*: Consider the hypothetical case where the dependency crate has an older edition (and thus eager type aliases), it exports a type alias with bounds & a where-clause (which are void but technically valid), the dependent crate has the latest edition (and thus lazy type aliases) and it uses that type alias. Arguably, the bounds should *not* be checked since at any time, the dependency crate should be allowed to change the bounds at will with a *non*-major version bump & without negatively affecting downstream crates. As for the reverse case (dependency: lazy type aliases, dependent: eager type aliases), I guess it rules out anything from slight confusion to mild annoyance from upstream crate authors that would be caused by the compiler ignoring the bounds of their type aliases in downstream crates with older editions. --- This fixes #114468 since before, my assumption that the type alias associated with a given weak projection was lazy (and therefore had its variances computed) did not necessarily hold in cross-crate scenarios (which [I kinda had a hunch about](https://github.com/rust-lang/rust/pull/114253#discussion_r1278608099)) as outlined above. Now it does hold. `@rustbot` label F-lazy_type_alias r? `@oli-obk`
-
由 Matthias Krüger 提交于
Remove arm crypto target feature Follow-up to https://github.com/rust-lang/stdarch/pull/1407. LLVM has moved away from a combined `crypto` feature on both aarch64 and arm, and we did the same on aarch64, but were deferred from doing the same on arm due to compatibility with older LLVM. As the minimum LLVM version has increased, we can now remove this (unstable) target feature on arm. r? `@Amanieu`
-
由 Matthias Krüger 提交于
Revert #98333 "Re-enable atomic loads and stores for all RISC-V targets" This reverts #98333. As said in https://github.com/rust-lang/rust/pull/98333#issuecomment-1666375293, `forced-atomics` target feature is also needed to enable atomic load/store on these targets (otherwise, libcalls are generated): https://godbolt.org/z/433qeG7vd However, `forced-atomics` target feature is currently broken (https://github.com/rust-lang/rust/issues/114153), so AFAIK, there is currently no way to enable atomic load/store (via core::intrinsics) on these targets properly. r? `@Amanieu`
-
由 Matthias Krüger 提交于
Warn when #[macro_export] is applied on decl macros The existing code checks if `#[macro_export]` is being applied to an item other than a macro, and warns in that case, but fails to take into account macros 2.0/decl macros, despite the attribute having no effect on these macros. This PR adds a special case for decl macros with the aforementioned attribute, so that the warning is a bit more precise. Instead of just saying "this attribute has no effect", hint towards the fact that decl macros get exported and resolved like regular items. It also removes a `#[macro_export]` attribute which was applied on one of `core`'s decl macros. - core: Remove #[macro_export] from `debug_assert_matches` - check_attrs: Warn when #[macro_export] is used on macros 2.0
-
由 Matthias Krüger 提交于
Avoid exporting __rust_alloc_error_handler_should_panic more than once. Exporting `__rust_alloc_error_handler_should_panic` multiple times causes `ld.gold` to balk with: `error: version script assignment of to symbol __rust_alloc_error_handler_should_panic failed: symbol not defined` Specifically this breaks builds of 1.70.0 and newer on DragonFly and YoctoProject with `ld.gold`. Builds with `ld.bfd` and `lld` should be unaffected. http://errors.yoctoproject.org/Errors/Details/708194/
-
由 bors 提交于
Update to LLVM 17 Expected LLVM 17.0.0 release date: Sep 5th Rust 1.73 release date: Oct 5th Compatibility changes in this PR: - Drop LLVM_RUSTLLVM check for target-cpu table, which no longer requires a patch with LLVM 17. - Update powerpc data layouts, which now include function alignment information. As usual, downgrade for older LLVM versions. - Adjust the stack-protector.rs test so that the stack smashing does not get optimized away. - Adjust path of crtbegin.c and crtend.c in compiler-rt. - Updated dist-riscv64-linux to use binutils 2.36 in order to recognize the zicsr feature, which is no longer part of the base ISA. - Fixed symlink for asm include directory on dist-various-2. We should use `/usr/include/x86_64-linux-gnu/asm` for the host, rather than `/usr/include/asm-generic`. Upstream patches: - [x] https://reviews.llvm.org/D156525 (backported) Perf run: https://perf.rust-lang.org/compare.html?start=f239bb6bea94d16d902c36d72b5cabdddefb3cab&end=8030d71a95a3ea79f5fc95232c32f9b78effb92d&stat=instructions:u Fixes #109671. Successful: dist-x86_64-linux, dist-aarch64-linux, dist-s390x-linux, dist-powerpc-linux, armhf-gnu, wasm32
-
由 Jakub Beránek 提交于
This makes it clearer that the LLVM is the host one (it doesn't necessarily have to be downloaded).
-
由 Arthur Cohen 提交于
The compiler should emit a more specific error when the `#[macro_export]` attribute is present on a decl macro, instead of silently ignoring it. This commit adds the required error message in rustc_passes/messages.ftl, as well as a note. A new variant is added to the `errors::MacroExport` enum, specifically for the case where the attribute is added to a macro 2.0.
-
由 Arthur Cohen 提交于
The `debug_assert_matches` macro was marked with the `#[macro_export]` attribute, despite being a declarative macro/macro 2.0, for which the exporting rules are similar to items. In fact, `#[macro_export]` on a decl macro has no effect on its visibility.
-
由 Michael Goulet 提交于
-
由 Michael Goulet 提交于
-
由 Nikita Popov 提交于
These types changed in LLVM 18, not LLVM 17.
-
由 Nikita Popov 提交于
We should symlink /usr/include/x86_64-linux-gnu/asm for the host triple, rather than /usr/include/asm-generic, which is used in the implementation for asm for specific triple, but shouldn't be used by itself.
-
由 Nikita Popov 提交于
The zicsr feature has been split off from the base ISA. A newer binutils version is required to recognize it.
-
由 Nikita Popov 提交于
These were moved into builtins by https://reviews.llvm.org/D153989.
-
由 Nikita Popov 提交于
Prevent fill from being (correctly) optimized away by passing the address of the alloca to black_box.
-
由 Nikita Popov 提交于
Function pointer alignment is specified since https://reviews.llvm.org/D147016.
-
由 Nikita Popov 提交于
The bundled version now uses the LLVM 17 code path.
-
由 Nikita Popov 提交于
-
由 bors 提交于
Use the correct `llvm-profdata` binary in `opt-dist` Turns out that we were probably using the wrong `llvm-profdata` binary in the PGO script all along. This should resolve the performance regressions of switching the host LLVM to 17 ([host `llvm-profdata`](https://github.com/rust-lang/rust/pull/114297#issuecomment-1660521361), [target `llvm-profdata`](https://github.com/rust-lang/rust/pull/114297#issuecomment-1661127032)]). r? `@nikic`
-
- 07 8月, 2023 15 次提交
-
-
由 bors 提交于
Rollup of 9 pull requests Successful merges: - #113568 (Fix spurious test failure with `panic=abort`) - #114196 (Bubble up nested goals from equation in `predicates_for_object_candidate`) - #114485 (Add trait decls to SMIR) - #114495 (Set max_atomic_width for AVR to 16) - #114496 (Set max_atomic_width for sparc-unknown-linux-gnu to 32) - #114510 (llvm-wrapper: adapt for LLVM API changes) - #114562 (stabilize abi_thiscall) - #114570 ([miri][typo] Fix a typo in a vector_block comment.) - #114573 (CI: do not hide error logs in a group) r? `@ghost` `@rustbot` modify labels: rollup
-
由 Matthias Krüger 提交于
CI: do not hide error logs in a group This PR avoids creating a GHA group at the very end of a CI workflow when some failure has happened. Before, when a failure has happened, its GHA group was not closed, however the clock drift check function would create a new group, which would actually close the group containing the error log, thus making errors hidden by default, which is not ideal. See discussion here: https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/GHA.20groups.20being.20closed.20on.20failures r? bootstrap
-
由 Matthias Krüger 提交于
[miri][typo] Fix a typo in a vector_block comment.
-
由 Matthias Krüger 提交于
stabilize abi_thiscall Closes https://github.com/rust-lang/rust/issues/42202, stabilizing the use of the "thiscall" ABI. FCP was substituted by a poll, and the poll has been accepted.
-
由 Matthias Krüger 提交于
llvm-wrapper: adapt for LLVM API changes No functional changes intended. Adapts llvm-wrapper for https://github.com/llvm/llvm-project/commit/65e57bbed06d55cab7bb64d54891d33ccb2d4159. Found by our experimental rust + llvm @ HEAD CI: https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/21304#0189c526-86cd-4db9-bdbc-dd0132dfc22b/197-500
-
由 Matthias Krüger 提交于
Set max_atomic_width for sparc-unknown-linux-gnu to 32 This is currently set to 64 https://github.com/rust-lang/rust/blob/90f0b24ad3e7fc0dc0e419c9da30d74629cd5736/compiler/rustc_target/src/spec/sparc_unknown_linux_gnu.rs#L8 However, AFAIK, this architecture doesn't support 64-bit atomics, and LLVM generates libcalls: https://godbolt.org/z/chzThWGG1 (Currently, attempts to run `cargo test` for this target result in "undefined reference to `__sync_val_compare_and_swap_8'" error. https://github.com/taiki-e/rust-cross-toolchain/commit/02efe1e74f2280f06662eaf275690883b2f9c7ae) r? `@Amanieu`
-
由 Matthias Krüger 提交于
Set max_atomic_width for AVR to 16 This is currently set to 0 https://github.com/rust-lang/rust/blob/90f0b24ad3e7fc0dc0e419c9da30d74629cd5736/compiler/rustc_target/src/spec/avr_gnu_base.rs#L26-L27 However, LLVM supports {8,16}-bit atomic load/store on AVR (support for RMW is still quite incomplete and only partially supported). https://github.com/llvm/llvm-project/blob/llvmorg-15.0.0/llvm/test/CodeGen/AVR/atomics/load8.ll#L5-L13 https://github.com/llvm/llvm-project/blob/llvmorg-15.0.0/llvm/test/CodeGen/AVR/atomics/load16.ll#L3-L12 https://github.com/llvm/llvm-project/blob/llvmorg-15.0.0/llvm/test/CodeGen/AVR/atomics/store.ll#L3-L22 cc #99668 r? `@Amanieu`
-
由 Matthias Krüger 提交于
Add trait decls to SMIR r? `@oli-obk` Closes https://github.com/rust-lang/project-stable-mir/issues/20
-
由 Matthias Krüger 提交于
Bubble up nested goals from equation in `predicates_for_object_candidate` This used to be needed for https://github.com/rust-lang/rust/pull/114036#discussion_r1273987510, but since it's no longer, I'm opening this as a separate PR. This also fixes one ICEing UI test: (`tests/ui/unboxed-closures/issue-53448.rs`) r? `@lcnr`
-
由 Matthias Krüger 提交于
Fix spurious test failure with `panic=abort` Description on why it happens and why the fix should work is in the code comments.
-
-
由 Pietro Albini 提交于
-
由 bors 提交于
Make `unconditional_recursion` warning detect recursive drops Closes #55388 Also closes #50049 unless we want to keep it for the second example which this PR does not solve, but I think it is better to track that work in #57965. r? `@oli-obk` since you are the mentor for #55388 Unresolved questions: - [x] There are two false positives that must be fixed before merging (see diff). I suspect the best way to solve them is to perform analysis after drop elaboration instead of before, as now, but I have not explored that any further yet. Could that be an option? **Answer:** Yes, that solved the problem. `@rustbot` label +T-compiler +C-enhancement +A-lint
-
由 Santiago Pastorino 提交于
-
由 Santiago Pastorino 提交于
-