-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 5 pull requests #119069
Rollup of 5 pull requests #119069
Conversation
Coverage marker statements should have no effect on codegen, but in some cases they could have the side-effect of creating a `func_coverage` entry for their enclosing function. That can lead to an ICE for functions that don't actually have any coverage spans.
This fixes WINE support
coverage: Skip instrumenting a function if no spans were extracted from MIR The immediate symptoms of rust-lang#118643 were fixed by rust-lang#118666, but some users reported that their builds now encounter another coverage-related ICE: ``` error: internal compiler error: compiler/rustc_codegen_llvm/src/coverageinfo/mapgen.rs:98:17: A used function should have had coverage mapping data but did not: (...) ``` I was able to reproduce at least one cause of this error: if no relevant spans could be extracted from a function, but the function contains `CoverageKind::SpanMarker` statements, then codegen still thinks the function is instrumented and complains about the fact that it has no coverage spans. This PR prevents that from happening in two ways: - If we didn't extract any relevant spans from MIR, skip instrumenting the entire function and don't create a `FunctionCoverateInfo` for it. - If coverage codegen sees a `CoverageKind::SpanMarker` statement, skip it early and avoid creating `func_coverage`. --- Fixes rust-lang#118850.
…Lapkin [AIX] Fix XCOFF metadata rust-lang#118344 accidentally changed the way to get metadata from XCOFF file and broken our internal CI. This PR reverts part of rust-lang#118344 .
Add better ICE messages for some undescriptive panics Add some better messages at some panics re: rust-lang#118955 I took a look at some others but either was not able to figure out what they did, or it was unclear what they should say instead. For example in the query system whether each time a poisoned value is matched upon if they should all just call `FatalError.raise()`
Replace `FileAllocationInfo` with `FileEndOfFileInfo` This fixes WINE support
…headers, r=fee1-dead Deny `~const` trait bounds in inherent impl headers Follow-up to rust-lang#117817. Implements rust-lang#117817 (comment). Fixes rust-lang#117004. r? fee1-dead or compiler
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: cda4736f1e In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (e004adb): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis 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.
CyclesResultsThis 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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 673.091s -> 672.726s (-0.05%) |
@rustbot label: +perf-regression-triaged |
Successful merges:
FileAllocationInfo
withFileEndOfFileInfo
#119051 (ReplaceFileAllocationInfo
withFileEndOfFileInfo
)~const
trait bounds in inherent impl headers #119059 (Deny~const
trait bounds in inherent impl headers)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup