-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Rollup of 7 pull requests #114604
Rollup of 7 pull requests #114604
Commits on Aug 2, 2023
-
Avoid exporting symbols 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 on DragonFly and YoctoProject with ld.gold. Builds with ld.bfd should be unaffected.
Alex Zepeda committedAug 2, 2023 Configuration menu - View commit details
-
Copy full SHA for 2e29d85 - Browse repository at this point
Copy the full SHA 2e29d85View commit details
Commits on Aug 5, 2023
-
Configuration menu - View commit details
-
Copy full SHA for b47e4a4 - Browse repository at this point
Copy the full SHA b47e4a4View commit details -
Configuration menu - View commit details
-
Copy full SHA for dddd219 - Browse repository at this point
Copy the full SHA dddd219View commit details
Commits on Aug 7, 2023
-
Configuration menu - View commit details
-
Copy full SHA for 5468336 - Browse repository at this point
Copy the full SHA 5468336View commit details -
Configuration menu - View commit details
-
Copy full SHA for fb9030d - Browse repository at this point
Copy the full SHA fb9030dView commit details -
Configuration menu - View commit details
-
Copy full SHA for ba4a2f7 - Browse repository at this point
Copy the full SHA ba4a2f7View commit details -
core: Remove #[macro_export] from
debug_assert_matches
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.
Configuration menu - View commit details
-
Copy full SHA for f177625 - Browse repository at this point
Copy the full SHA f177625View commit details -
check_attrs: Warn when #[macro_export] is used on macros 2.0
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.
Configuration menu - View commit details
-
Copy full SHA for bdf4e3d - Browse repository at this point
Copy the full SHA bdf4e3dView commit details -
This makes it clearer that the LLVM is the host one (it doesn't necessarily have to be downloaded).
Configuration menu - View commit details
-
Copy full SHA for 65e468f - Browse repository at this point
Copy the full SHA 65e468fView commit details
Commits on Aug 8, 2023
-
Rollup merge of rust-lang#114376 - inferiorhumanorgans:rustc-codegen-…
…ssa-duplicate-export, r=wesleywiser 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/
Configuration menu - View commit details
-
Copy full SHA for 328e978 - Browse repository at this point
Copy the full SHA 328e978View commit details -
Rollup merge of rust-lang#114413 - CohenArthur:warn-macro-export-decl…
…-macros, r=cjgillot 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
Configuration menu - View commit details
-
Copy full SHA for 42cdc7d - Browse repository at this point
Copy the full SHA 42cdc7dView commit details -
Rollup merge of rust-lang#114497 - taiki-e:revert-riscv-atomic, r=Ama…
…nieu Revert rust-lang#98333 "Re-enable atomic loads and stores for all RISC-V targets" This reverts rust-lang#98333. As said in rust-lang#98333 (comment), `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 (rust-lang#114153), so AFAIK, there is currently no way to enable atomic load/store (via core::intrinsics) on these targets properly. r? `@Amanieu`
Configuration menu - View commit details
-
Copy full SHA for 6f36f1f - Browse repository at this point
Copy the full SHA 6f36f1fView commit details -
Rollup merge of rust-lang#114500 - taiki-e:arm-crypto, r=Amanieu
Remove arm crypto target feature Follow-up to rust-lang/stdarch#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`
Configuration menu - View commit details
-
Copy full SHA for 28ee1a9 - Browse repository at this point
Copy the full SHA 28ee1a9View commit details -
Rollup merge of rust-lang#114566 - fmease:type-alias-laziness-is-crat…
…e-specific, r=oli-obk 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 rust-lang#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](rust-lang#114253 (comment))) as outlined above. Now it does hold. `@rustbot` label F-lazy_type_alias r? `@oli-obk`
Configuration menu - View commit details
-
Copy full SHA for 3cd0a10 - Browse repository at this point
Copy the full SHA 3cd0a10View commit details -
Rollup merge of rust-lang#114594 - compiler-errors:new-solver-resolve…
…-aliases, r=lcnr 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`
Configuration menu - View commit details
-
Copy full SHA for 418b91a - Browse repository at this point
Copy the full SHA 418b91aView commit details -
Rollup merge of rust-lang#114596 - Kobzol:opt-dist-host, r=lqd
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: rust-lang#114344 (comment) r? `@lqd`
Configuration menu - View commit details
-
Copy full SHA for 07b2c97 - Browse repository at this point
Copy the full SHA 07b2c97View commit details