Add `type_ascribe!` macro as placeholder syntax for type ascription
This makes it still possible to test the internal semantics of type ascription even once the `:`-syntax is removed from the parser. The macro now gets used in a bunch of UI tests that test the semantics and not syntax of type ascription.
I might have forgotten a few tests but this should hopefully be most of them. The remaining ones will certainly be found once type ascription is removed from the parser altogether.
Part of #101728
rustc_ast_lowering: Stop lowering imports into multiple items
Lower them into a single item with multiple resolutions instead.
This also allows to remove additional `NodId`s and `DefId`s related to those additional items.
Lower them into a single item with multiple resolutions instead.
This also allows to remove additional `NodId`s and `DefId`s related to those additional items.
rustdoc: remove redundant CSS `div.desc { display: block }`
DIV tags have block display by default. It is from when this rule used to target a SPAN tag, but became redundant in 4bd6748bb9.
`#![custom_mir]`: Various improvements
This PR makes a bunch of improvements to `#![custom_mir]`. Ideally this would be 4 PRs, one for each commit, but those would take forever to get merged and be a pain to juggle. Should still be reviewed one commit at a time though.
### Commit 1: Support arbitrary `let`
Before this change, all locals used in the body need to be declared at the top of the `mir!` invocation, which is rather annoying. We attempt to change that.
Unfortunately, we still have the requirement that the output of the `mir!` macro must resolve, typecheck, etc. Because of that, we can't just accept this in the THIR -> MIR parser because something like
```rust
{
let x = 0;
Goto(other)
}
other = {
RET = x;
Return()
}
```
will fail to resolve. Instead, the implementation does macro shenanigans to find the let declarations and extract them as part of the `mir!` macro. That *works*, but it is fairly complicated and degrades debuginfo by quite a bit. Specifically, the spans for any statements and declarations that are affected by this are completely wrong. My guess is that this is a net improvement though.
One way to recover some of the debuginfo would be to not support type annotations in the `let` statements, which would allow us to parse like `let $stmt:stmt`. That seems quite surprising though.
### Commit 2: Parse consts
Reuses most of the const parsing from regular Mir building for building custom mir
### Commit 3: Parse statics
Statics are slightly weird because the Mir primitive associated with them is a reference/pointer to them, so this is factored out separately.
### Commit 4: Fix some spans
A bunch of the spans were non-ideal, so we adjust them to be much more helpful.
r? `@oli-obk`
rustdoc: clean up sidebar link CSS
Group `text-overflow: ellipses` along with `white-space: nowrap`. It makes no sense to try to apply it to links with `overflow-wrap: anywhere`, because it can't actually make ellipses when that's turned on.
Simplify the selector for the 25rem left padding on sidebar links, to match up with the style for the container left padding that makes room for it.
rustdoc: add comment to confusing CSS `main { min-width: 0 }`
This CSS was added in cad0fce205, but the reason why it was necessary was unclear. This comment makes it clear.
Group `text-overflow: ellipses` along with `white-space: nowrap`. It makes
no sense to try to apply it to links with `overflow-wrap: anywhere`, because
it can't actually make ellipses when that's turned on.
Simplify the selector for the 25rem left padding on sidebar links, to match
up with the style for the container left padding that makes room for it.
Some initial normalization method changes
1. Rename `AtExt::normalize` to `QueryNormalizeExt::query_normalize` (using the `QueryNormalizer`)
2. Introduce `NormalizeExt::normalize` to replace `partially_normalize_associated_types_in` (using the `AssocTypeNormalizer`)
3. Rename `FnCtxt::normalize_associated_types_in` to `FnCtxt::normalize`
4. Remove some unused other normalization fns in `Inherited` and `FnCtxt`
Also includes one drive-by where we're no longer creating a `FnCtxt` inside of `check_fn`, but passing it in. This means we don't need such weird `FnCtxt` construction logic.
Stacked on top of #104835 for convenience.
r? types
Rollup of 5 pull requests
Successful merges:
- #104697 (Restore control flow on error in EUV)
- #104811 (feat: implement TcpStream shutdown for wasm32-wasi)
- #105039 (Fix an ICE parsing a malformed literal in `concat_bytes!`.)
- #105071 (Add Nicholas Nethercote to `.mailmap`.)
- #105079 (Add bots to `.mailmap`)
Failed merges:
- #105074 (Add Nicholas Bishop to `.mailmap`)
r? `@ghost`
`@rustbot` modify labels: rollup
Restore control flow on error in EUV
cc `@Nilstrieb`
Fix#104649
Since #98574 refactored a piece of scrutinee memory categorization out as a subroutine, there is a subtle change in handling match arms especially when the categorization process faults and bails. In the correct case, it is not supposed to continue to process the arms any more. This PR restores the original control flow in EUV.
I promise to add a compile-fail test to demonstrate that this indeed fixes the issue after coming back from a nap.
codegen-llvm: never combine DSOLocal and DllImport
Prevent DllImport from being attached to DSOLocal definitions in the LLVM IR. The combination makes no sense, since definitions local to the compilation unit will never be imported from external objects.
Additionally, LLVM will refuse the IR if it encounters the combination (introduced in [1]):
```
if (GV.hasDLLImportStorageClass())
Assert(!GV.isDSOLocal(),
"GlobalValue with DLLImport Storage is dso_local!", &GV);
```
Right now, codegen-llvm will only apply DllImport to constants and rely on call-stubs for functions. Hence, we simply extend the codegen of constants to skip DllImport for any local definitions.
This was discovered when switching the EFI targets to the static relocation model [2]. With this fixed, we can start another attempt at this.
[1] 509132b368
[2] https://github.com/rust-lang/rust/issues/101656