Add `#[track_caller]` to `mirbug`
When a "'no errors encountered even though `delay_span_bug` issued" error results from the `mirbug` function, the file location information points to the `mirbug` function itself, rather than its caller. This doesn't make sense, since the caller is the real source of the bug. Adding `#[track_caller]` will produce diagnostics that are more useful to anyone fixing the ICE.
Prefer projection candidates instead of param_env candidates for Sized predicates
Fixes#89352
Also includes some drive by logging and verbose printing changes that I found useful when debugging this, but I can remove this if needed.
This is a little hacky - but imo no more than the rest of `candidate_should_be_dropped_in_favor_of`. Importantly, in a Chalk-like world, both candidates should be completely compatible.
r? ```@nikomatsakis```
rustdoc: avoid many `Symbol` to `String` conversions.
Particularly when constructing file paths and fully qualified paths.
This avoids a lot of allocations, speeding things up on almost all
examples.
r? `@GuillaumeGomez`
Rollup of 9 pull requests
Successful merges:
- #92045 (Don't fall back to crate-level opaque type definitions.)
- #92381 (Suggest `return`ing tail expressions in async functions)
- #92768 (Partially stabilize `maybe_uninit_extra`)
- #92810 (Deduplicate box deref and regular deref suggestions)
- #92818 (Update documentation for doc_cfg feature)
- #92840 (Fix some lints documentation)
- #92849 (Clippyup)
- #92854 (Use the updated Rust logo in rustdoc)
- #92864 (Fix a missing dot in the main item heading)
Failed merges:
- #92838 (Clean up some links in RELEASES)
r? `@ghost`
`@rustbot` modify labels: rollup
Deduplicate box deref and regular deref suggestions
Remove the suggestion code special-cased for Box deref.
r? ```@camelid```
since you introduced the code in #90627
Suggest `return`ing tail expressions in async functions
This PR fixes#92308.
Previously, the suggestion to `return` tail expressions (introduced in #81769) did not apply to `async` functions, as the suggestion checked whether the types were equal disregarding `impl Future<Output = T>` syntax sugar for `async` functions. This PR changes that in order to fix a potential papercut.
I'm not sure if this is the "right" way to do this, so if there is a better way then please let me know.
I amended an existing test introduced in #81769 to add a regression test for this, if you think I should make a separate test I will.
Don't fall back to crate-level opaque type definitions.
That would just hide bugs, as it works accidentally if the opaque type is defined at the crate level.
Only works after #90948 which worked by accident for our entire test suite.
This was originally introduced in #10916 as a way to remove all landing
pads when performing LTO. However this is no longer necessary today
since rustc properly marks all functions and call-sites as nounwind
where appropriate.
In fact this is incorrect in the presence of `extern "C-unwind"` which
must create a landing pad when compiled with `-C panic=abort` so that
foreign exceptions are caught and properly turned into aborts.
Swift has specific syntax that desugars to `Option<T>` similar to our
`?` operator, which means that people might try to use it in Rust. Parse
it and gracefully recover.
Currently all generators are named with a `generator$N` suffix,
regardless of where they come from. This means an `async fn` shows up as
a generator in stack traces, which can be surprising to async
programmers since they should not need to know that async functions are
implementated using generators.
This change generators a different name depending on the generator kind,
allowing us to tell whether the generator is the result of an async
block, an async closure, an async fn, or a plain generator.
Closure capture cleanup & refactor
Follow up of #89648
Each commit is self-contained and the rationale/changes are documented in the commit message, so it's advisable to review commit by commit.
The code is significantly cleaner (at least IMO), but that could have some perf implication, so I'd suggest a perf run.
r? `@wesleywiser`
cc `@arora-aman`
rustc_metadata: Stop passing `CrateMetadataRef` by reference (step 1)
It's already a (fat) reference.
Double referencing it creates lifetime issues for its methods that want to return iterators.
---
Extracted from https://github.com/rust-lang/rust/pull/92245 for a perf run.
The PR changes a lot of symbol names due to function signature changes, so it's hard to do differential profiling, let's spend some machine time instead.
[code coverage] Fix missing dead code in modules that are never called
The issue here is that the logic used to determine which CGU to put the dead function stubs in doesn't handle cases where a module is never assigned to a CGU (which is what happens when all of the code in the module is dead).
The partitioning logic also caused issues in #85461 where inline functions were duplicated into multiple CGUs resulting in duplicate symbols.
This commit fixes the issue by removing the complex logic used to assign dead code stubs to CGUs and replaces it with a much simpler model: we pick one CGU to hold all the dead code stubs. We pick a CGU which has exported items which increases the likelihood the linker won't throw away our dead functions and we pick the smallest to minimize the impact on compilation times for crates with very large CGUs.
Fixes#91661Fixes#86177Fixes#85718Fixes#79622
r? ```@tmandry```
cc ```@richkadel```
This PR is not urgent so please don't let it interrupt your holidays! 🎄🎁
Welcome opaque types into the fold
r? ```@nikomatsakis``` because idk who else to bug on the type_op changes
The commits have explanations in them. The TLDR is that
* 5c46002273 stops the "recurse and replace" scheme that replaces opaque types with their canonical inference var by just doing that ahead of time
* bdeeb07bf6 does not affect anything on master afaict, but since opaque types generate obligations when instantiated, and lazy TAIT instantiates opaque types *everywhere*, we need to properly handle obligations here instead of just hoping no problematic obligations ever come up.
Make rlib metadata strip works with MIPSr6 architecture
Because MIPSr6 has many differences with previous MIPSr2 arch, the previous rlib metadata stripping code in `rustc_codegen_ssa` is only for MIPSr2/r3/r5 (which share the same elf e_flags).
This commit fixed this problem. It makes `rustc_codegen_ssa` happy when compiling rustc for MIPSr6 target or hosts.
e_flags REF: e356027016/llvm/include/llvm/BinaryFormat/ELF.h (L562)
Now, multipart suggestions are used instead of `span_to_snippet`, which
improves code quality, makes the suggestion work even without access to
source code, and, most importantly, improves the rendering of the
suggestion.
