Use `pprust` to print attributes in rustdoc
Fixes https://github.com/rust-lang/rust/issues/69559.
I'm not sure what the original motivation was for the `render_attribute`, so I may be missing something, but replacing it with `pprust::attribute_to_string` seems to give the intended output (modulo some spacing idiosyncrasies).
r? @GuillaumeGomez
def_collector: Fully visit async functions
We forgot to visit attributes previously, it caused ICEs.
Special treatment of async functions is also moved from `visit_item` to `visit_fn` to reuse more of the default visitor.
Fixes https://github.com/rust-lang/rust/issues/67778.
Change "method" to "associated function"
r? @matthewjasper
cc @Centril @eddyb #67742
I'm opening this mostly as a test to see what the diagnostic changes would be. It seems that this makes them somewhat more verbose, and I'm not sure it's worth it...
The relevant changes are the last two commits (it is rebased on top of #67742)
Emit 1-based column numbers in debuginfo
* Use byte offsets instead of char position offsets. Resolves#67360.
* Use 1-based offsets instead of 0-based ones. Resolves#65437.
* Consistently omit column information for msvc targets, matching clang behaviour (previously columns have been omitted from `DILocation`, but not from `DILexicalBlock`).
Add `mir-opt` test for more precise drop elaboration
Depends on #69676. This test should ensure that the problem fixed in that PR does not reoccur.
This has been split out from #69676 since the test fails on certain targets where no cleanup blocks are emitted. I have to find the correct `ignore` directives.
r? @oli-obk
Don't store locals in generators that are immediately overwritten with the resume argument
This fixes https://github.com/rust-lang/rust/issues/69672 and makes https://github.com/rust-lang/rust/pull/69033 pass the async fn size tests again (in other words, there will be no size regression of async fn if both this and https://github.com/rust-lang/rust/pull/69033 land).
~~This is a small botch and I'd rather have a more precise analysis, but that seems much harder to pull off, so this special-cases `Yield` terminators that store the resume argument into a simple local (ie. without any field projections) and explicitly marks that local as "not live" in the suspend point of that yield. We know that this local does not need to be stored in the generator for this suspend point because the next resume would immediately overwrite it with the passed-in resume argument anyways. The local might still end up in the state if it is used across another yield.~~ (this now properly updates the dataflow framework to handle this case)
Optimize catch_unwind to match C++ try/catch
This refactors the implementation of catching unwinds to allow LLVM to inline the "try" closure directly into the happy path, avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown.
https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably, the codegen is *exactly the same* if `-Cpanic=abort` is passed, which is clearly not great.
This PR, on the other hand, generates the following assembly:
```asm
# -Cpanic=unwind:
push rbx
mov ebx,0x2a
call QWORD PTR [rip+0x1c53c] # <happy>
mov eax,ebx
pop rbx
ret
mov rdi,rax
call QWORD PTR [rip+0x1c537] # cleanup function call
call QWORD PTR [rip+0x1c539] # <unfortunate>
mov ebx,0xd
mov eax,ebx
pop rbx
ret
# -Cpanic=abort:
push rax
call QWORD PTR [rip+0x20a1] # <happy>
mov eax,0x2a
pop rcx
ret
```
Fixes#64224, and resolves#64222.
miri engine: fix treatment of abort intrinsic
I screwed up in https://github.com/rust-lang/rust/pull/69830 and added `abort` to the wrong block of intrinsics, namely the one that actually has a return place. So that branch was never actually reached.
r? @oli-obk
Add support for LLVM globals corresponding to miri allocations should be named alloc123
Adds support for this request from @eddyb in #69134:
> That is, if -Zfewer-names is false (usually only because of --emit=llvm-ir), we should use the same name for LLVM globals we generate out of miri allocs as #67133 does in MIR output (allocN).
>
>This way, we can easily see the mapping between MIR and LLVM IR (and it shouldn't be any costlier for regular compilation, which would continue to use unnamed globals).
r? @eddyb
cc @oli-obk
