Fix error report for size overflow from transmute
Fixes#115402
The span in the error reporting always points to the `dst`, this is an old issue, I may open another PR to fix it.
Make if let guard parsing consistent with normal guards
- Add tests that struct expressions are not allowed in `if let` and `while let` (no change, consistent with `if` and `while`)
- Allow struct expressions in `if let` guards (consistent with `if` guards).
r? `@cjgillot`
Closes#93817
cc #51114
Use relative positions inside a SourceFile.
This allows to remove the normalization of start positions for hashing, and simplify allocation of global address space.
cc `@Zoxc`
Rollup of 3 pull requests
Successful merges:
- #114794 (clarify safety documentation of ptr::swap and ptr::copy)
- #115397 (Add support to return value in StableMIR interface and not crash due to compilation error)
- #115559 (implied bounds: do not ICE on unconstrained region vars)
Failed merges:
- #115532 (Implement SMIR generic parameter instantiation)
r? `@ghost`
`@rustbot` modify labels: rollup
Add support to return value in StableMIR interface and not crash due to compilation error
Invoking `StableMir::run()` on a crate that has any compilation error was crashing the entire process. Instead, return a `CompilerError` so the user knows compilation did not succeed. I believe ICE will also be converted to `CompilerError`.
I'm also adding a possibility for the callback to return a value. I think it will be handy for users (at least it was for my current task of implementing a tool to validate stable-mir). However, if people disagree, I can remove that.
Currently we stop compilation, but some users might want to keep going.
This is needed for us to test against rustc tests. Other tools, such as
Kani, also implements parts of their logic as a backend so it is
important for compilation to continue.
Invoking StableMir::run() on a crate that has any compilation error was
crashing the entire process. Instead, return a `CompilerError` so the
user knows compilation did not succeed.
I believe ICE will also be converted to `CompilerError`.
I'm also adding a return value to the callback, because I think it will
be handy for users (at least it was for my current task of implementing
a tool to validate stable-mir). However, if people disagree,
I can remove that.
coverage: Explicitly test the coverage maps produced by codegen/LLVM
Our existing coverage tests verify the output of end-to-end coverage reports, but we don't have any way to test the specific mapping information (code regions and their associated counters) that are emitted by `rustc_codegen_llvm` and LLVM. That makes it harder to to be confident in changes that would modify those mappings (whether deliberately or accidentally).
This PR addresses that by adding a new `coverage-map` test suite that does the following:
- Compiles test files to LLVM IR assembly (`.ll`)
- Feeds those IR files to a custom tool (`src/tools/coverage-dump`) that extracts and decodes coverage mappings, and prints them in a more human-readable format
- Checks the output of that tool against known-good snapshots
---
I recommend excluding the last commit while reviewing the main changes, because that last commit is just ~40 test files copied over from `tests/run-coverage`, plus their blessed coverage-map snapshots and a readme file. Those snapshots aren't really intended to be checked by hand; they're mostly there to increase the chances that an unintended change to coverage maps will be observable (even if it requires relatively specific circumstances to manifest).
Rollup of 7 pull requests
Successful merges:
- #113510 (Document soundness of Integer -> Pointer -> Integer conversions in `const` contexts.)
- #114412 (document our assumptions about symbols provided by the libc)
- #114813 (explain why we can mutate the FPU control word)
- #115523 (improve `AttrTokenStream`)
- #115536 (interpret: make MemPlace, Place, Operand types private to the interpreter)
- #115540 (Support debuginfo for custom MIR.)
- #115563 (llvm-wrapper: adapt for LLVM API change)
r? `@ghost`
`@rustbot` modify labels: rollup
support `{disable,enable}-patch-binaries-for-nix` in configure.py
Provide the control of `patch-binaries-for-nix` flag from configure.py without requiring manual editing.
It's useful when:
bf1e3f31f9/src/bootstrap/bootstrap.py (L661-L667)
Add `fmease` to rustdoc review rotations
`@fmease` asked me if it was okay for them to be part of the rustdoc review rotation. Since they are already reviewing a lot of rustdoc PRs, I think it's fine to add them to the rotation.
What do you think `@rust-lang/rustdoc` ?
r? rust-lang/rustdoc
Retry download of rustc-perf in opt-dist
This should help resolving spurious network errors. It also increases the timeout for the archive download.
r? `@Mark-Simulacrum`
Rollup of 5 pull requests
Successful merges:
- #115353 (Emit error instead of ICE when optimized MIR is missing)
- #115488 (Take `&mut Results` in `ResultsVisitor`)
- #115492 (Allow `large_assignments` for Box/Arc/Rc initialization)
- #115519 (Don't ICE on associated type projection without feature gate in new solver)
- #115534 (Expose more information with DefId in smir)
r? `@ghost`
`@rustbot` modify labels: rollup
Expose more information with DefId in smir
Currently `Debug` for `DefId` doesn't provide enough information, this changes so that we get `usize` of the `DefId` and the name of it.
r? `@oli-obk`
Don't ICE on associated type projection without feature gate in new solver
Self-explanatory, we should avoid ICEs when the feature gate is not enabled. Continue to ICE when the feature gate *is* enabled, though.
Fixes#115500
Allow `large_assignments` for Box/Arc/Rc initialization
Does the `stop linting in box/arc initialization` task of #83518.
r? `@oli-obk` who is E-mentor.
The output of these tests is too complicated to comfortably verify by hand, but
we can still use them to observe changes to the underlying mappings produced by
codegen/LLVM.
If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or
MIR optimizations), it should usually be OK to just `--bless` them, as long as
the `run-coverage` test suite still works.
