Rollup of 7 pull requests #114604

matthiaskrgr · 2023-08-08T01:30:57Z

Successful merges:

Avoid exporting __rust_alloc_error_handler_should_panic more than once. #114376 (Avoid exporting __rust_alloc_error_handler_should_panic more than once.)
Warn when #[macro_export] is applied on decl macros #114413 (Warn when #[macro_export] is applied on decl macros)
Revert #98333 "Re-enable atomic loads and stores for all RISC-V targets" #114497 (Revert Re-enable atomic loads and stores for all RISC-V targets #98333 "Re-enable atomic loads and stores for all RISC-V targets")
Remove arm crypto target feature #114500 (Remove arm crypto target feature)
Make the laziness of type aliases dependent on the defining crate #114566 (Store the laziness of type aliases in their DefKind)
Structurally normalize weak and inherent in new solver #114594 (Structurally normalize weak and inherent in new solver)
Rename method in opt-dist #114596 (Rename method in opt-dist)

r? @ghost
@rustbot modify labels: rollup

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.

…anieu" This reverts commit 90f0b24, reversing changes made to e173a8e.

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.

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.

This makes it clearer that the LLVM is the host one (it doesn't necessarily have to be downloaded).

…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/

…-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

…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`

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`

…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`

…-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`

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 · 2023-08-08T01:31:13Z

@bors r+ rollup=never p=7

bors · 2023-08-08T01:31:15Z

📌 Commit 07b2c97 has been approved by matthiaskrgr

It is now in the queue for this repository.

bors · 2023-08-08T02:27:42Z

⌛ Testing commit 07b2c97 with merge 8e7fd55...

bors · 2023-08-08T05:02:14Z

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing 8e7fd55 to master...

rust-timer · 2023-08-08T05:04:12Z

📌 Perf builds for each rolled up PR:

PR#	Message	Perf Build Sha
#114376	Avoid exporting __rust_alloc_error_handler_should_panic mor…	`eacd1c96d9458241e06c3e2ee14779280be9186b` (link)
#114413	Warn when #[macro_export] is applied on decl macros	`f4b0287b9a66e0c27a96b383a0efe8b10e1fd1a8` (link)
#114497	Revert #98333 "Re-enable atomic loads and stores for all RI…	`3ce787e8ba6ab2f89cf94423c33c4635b4c9a5b3` (link)
#114500	Remove arm crypto target feature	`c5e222467cd07c82cb79fb7d9d5cbf3a8cbbf20b` (link)
#114566	Store the laziness of type aliases in their `DefKind`	`383d7dbb460801e6bce235e0f2af9366459603fc` (link)
#114594	Structurally normalize weak and inherent in new solver	`0e990905571547422756ed5b48ee8057572ea74c` (link)
#114596	Rename method in `opt-dist`	`520a21bf447e9c4d12e1b8187cac32959e62445c` (link)

previous master: 443c3161dd

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

rust-timer · 2023-08-08T09:44:48Z

Finished benchmarking commit (8e7fd55): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.4%	[0.4%, 2.0%]	3
Regressions ❌ (secondary)	1.2%	[1.1%, 1.3%]	6
Improvements ✅ (primary)	-0.7%	[-0.9%, -0.4%]	2
Improvements ✅ (secondary)	-1.0%	[-1.5%, -0.5%]	2
All ❌✅ (primary)	0.5%	[-0.9%, 2.0%]	5

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.5%	[1.9%, 3.1%]	2
Improvements ✅ (primary)	-2.3%	[-2.5%, -2.1%]	2
Improvements ✅ (secondary)	-2.1%	[-2.3%, -2.0%]	3
All ❌✅ (primary)	-2.3%	[-2.5%, -2.1%]	2

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.0%	[0.0%, 0.0%]	8
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.0%	[0.0%, 0.0%]	8

Bootstrap: 630.826s -> 631.452s (0.10%)

lqd · 2023-08-08T10:27:45Z

@rust-timer build 0e990905571547422756ed5b48ee8057572ea74c

rust-timer · 2023-08-09T03:49:00Z

Finished benchmarking commit (0e990905571547422756ed5b48ee8057572ea74c): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.1%	[0.2%, 2.0%]	4
Regressions ❌ (secondary)	1.1%	[1.0%, 1.3%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.1%	[0.2%, 2.0%]	4

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.8%	[2.1%, 3.6%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.2%	[-2.2%, -2.2%]	1
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 630.826s -> 633.071s (0.36%)

lqd · 2023-08-09T06:21:03Z

If it’s not noise happening twice, it looks like #114594 is involved @compiler-errors: it may have changed common code and not just the new solver? (typeck in particular)

compiler-errors · 2023-08-09T06:25:29Z

I don't think so -- the only change that affects the old solver is replacing some resolve_vars_with_obligations calls with try_structurally_resolve_type calls, but the latter just calls the former when the old solver is active.

Addendum: #114594 (comment)

lqd · 2023-08-09T17:11:40Z

@compiler-errors has opened #114648 which will only apply #114594 to the new solver 🙏

Let's mark this PR triaged: @rustbot label: +perf-regression-triaged

Only resolve target type in `try_coerce` in new solver Only needed in new solver, seems to affect perf in old solver. cc rust-lang#114604/rust-lang#114594

Alex Zepeda and others added 16 commits August 2, 2023 11:02

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

b47e4a4

…anieu" This reverts commit 90f0b24, reversing changes made to e173a8e.

Remove arm crypto target feature

dddd219

Store the laziness of type aliases in the DefKind

5468336

Structurally normalize weak and inherent too

fb9030d

Resolve target type of coercion

ba4a2f7

Rename method in opt-dist

65e468f

This makes it clearer that the LLVM is the host one (it doesn't necessarily have to be downloaded).

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 8, 2023

bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 8, 2023

bors merged commit 8e7fd55 into rust-lang:master Aug 8, 2023
11 checks passed

rustbot added this to the 1.73.0 milestone Aug 8, 2023

rustbot added the perf-regression Performance regression. label Aug 8, 2023

This comment has been minimized.

Sign in to view

compiler-errors mentioned this pull request Aug 9, 2023

Structurally normalize weak and inherent in new solver #114594

Merged

compiler-errors mentioned this pull request Aug 9, 2023

Only resolve target type in try_coerce in new solver #114648

Merged

rustbot added the perf-regression-triaged The performance regression has been triaged. label Aug 9, 2023

matthiaskrgr deleted the rollup-o1jltfn branch March 16, 2024 18:19

lqd mentioned this pull request Apr 10, 2024

[ICE][miscompile] segv with combined atomic operation and nonnull pointer arithmetic in incremental build #123695

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Rollup of 7 pull requests #114604

Rollup of 7 pull requests #114604

matthiaskrgr commented Aug 8, 2023

matthiaskrgr commented Aug 8, 2023

bors commented Aug 8, 2023

bors commented Aug 8, 2023

bors commented Aug 8, 2023

rust-timer commented Aug 8, 2023

rust-timer commented Aug 8, 2023

lqd commented Aug 8, 2023

This comment has been minimized.

rust-timer commented Aug 9, 2023

lqd commented Aug 9, 2023 •

edited

Loading

compiler-errors commented Aug 9, 2023 •

edited

Loading

lqd commented Aug 9, 2023

Rollup of 7 pull requests #114604

Rollup of 7 pull requests #114604

Conversation

matthiaskrgr commented Aug 8, 2023

matthiaskrgr commented Aug 8, 2023

bors commented Aug 8, 2023

bors commented Aug 8, 2023

bors commented Aug 8, 2023

rust-timer commented Aug 8, 2023

rust-timer commented Aug 8, 2023

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

lqd commented Aug 8, 2023

This comment has been minimized.

rust-timer commented Aug 9, 2023

Overall result: ❌ regressions - ACTION NEEDED

lqd commented Aug 9, 2023 • edited Loading

compiler-errors commented Aug 9, 2023 • edited Loading

lqd commented Aug 9, 2023

lqd commented Aug 9, 2023 •

edited

Loading

compiler-errors commented Aug 9, 2023 •

edited

Loading