Skip to content
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

Merged
merged 16 commits into from
Aug 8, 2023
Merged

Rollup of 7 pull requests #114604

merged 16 commits into from
Aug 8, 2023

Commits on Aug 2, 2023

  1. 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 committed Aug 2, 2023
    Configuration menu
    Copy the full SHA
    2e29d85 View commit details
    Browse the repository at this point in the history

Commits on Aug 5, 2023

  1. Revert "Auto merge of rust-lang#98333 - SimonSapin:riscv-atomic, r=Am…

    …anieu"
    
    This reverts commit 90f0b24, reversing
    changes made to e173a8e.
    taiki-e committed Aug 5, 2023
    Configuration menu
    Copy the full SHA
    b47e4a4 View commit details
    Browse the repository at this point in the history
  2. Configuration menu
    Copy the full SHA
    dddd219 View commit details
    Browse the repository at this point in the history

Commits on Aug 7, 2023

  1. Configuration menu
    Copy the full SHA
    5468336 View commit details
    Browse the repository at this point in the history
  2. Configuration menu
    Copy the full SHA
    fb9030d View commit details
    Browse the repository at this point in the history
  3. Configuration menu
    Copy the full SHA
    ba4a2f7 View commit details
    Browse the repository at this point in the history
  4. 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.
    CohenArthur committed Aug 7, 2023
    Configuration menu
    Copy the full SHA
    f177625 View commit details
    Browse the repository at this point in the history
  5. 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.
    CohenArthur committed Aug 7, 2023
    Configuration menu
    Copy the full SHA
    bdf4e3d View commit details
    Browse the repository at this point in the history
  6. Rename method in opt-dist

    This makes it clearer that the LLVM is the host one (it doesn't necessarily have to be downloaded).
    Kobzol committed Aug 7, 2023
    Configuration menu
    Copy the full SHA
    65e468f View commit details
    Browse the repository at this point in the history

Commits on Aug 8, 2023

  1. 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/
    matthiaskrgr authored Aug 8, 2023
    Configuration menu
    Copy the full SHA
    328e978 View commit details
    Browse the repository at this point in the history
  2. 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
    matthiaskrgr authored Aug 8, 2023
    Configuration menu
    Copy the full SHA
    42cdc7d View commit details
    Browse the repository at this point in the history
  3. 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`
    matthiaskrgr authored Aug 8, 2023
    Configuration menu
    Copy the full SHA
    6f36f1f View commit details
    Browse the repository at this point in the history
  4. 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`
    matthiaskrgr authored Aug 8, 2023
    Configuration menu
    Copy the full SHA
    28ee1a9 View commit details
    Browse the repository at this point in the history
  5. 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`
    matthiaskrgr authored Aug 8, 2023
    Configuration menu
    Copy the full SHA
    3cd0a10 View commit details
    Browse the repository at this point in the history
  6. 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`
    matthiaskrgr authored Aug 8, 2023
    Configuration menu
    Copy the full SHA
    418b91a View commit details
    Browse the repository at this point in the history
  7. 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`
    matthiaskrgr authored Aug 8, 2023
    Configuration menu
    Copy the full SHA
    07b2c97 View commit details
    Browse the repository at this point in the history