Render extern blocks in `file_structure`

Support new #[rustc_intrinsic] attribute and fallback bodies

minor: Don't try to auto-publish text-edit

minor: Enable triagebot `transfer` feature

…ased on new `all_supertraits(…)` method

It's been a year since we last bumped this (see rust-lang#15904), and VS Code
1.83 is the first version that supports LSP 3.17.5 (via
vscode-languageclient 9.0.1).

https://code.visualstudio.com/updates/v1_83#_language-server-protocol

minor: Rename `dyn compatible` to `dyn-compatible`

editors/code: Change minimum VS Code from 1.78 to 1.83

…ported ones

…ine-config

editors/code: Update supported debug engines in config

…abel

Replace Design label with C-Architecture

…its_accessors

internal: Add public `direct_supertraits(…)` & `all_supertraits(…)` accessor methods to `hir::Trait`

I did the raw pointers in 125701, but apparently forgot `NonNull`.

…ng for the completion item to resolve

…olve-indexing

Use completion item indices instead of property matching when searching for the completion item to resolve

Using "having" in both the leading sentence and the bullets is unnecessary.
It makes it read as "it is only possible to have having several immutable...".

add a test

add github issue link to description of the test

replace new ThinVec with clear()

Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>

…lment errors

mew

Remove attributes from generics in built-in derive macros

Related issue rust-lang#132561

Removes all attributes from generics in the expanded implementations of built-in derive macros.

Feature gate yield expressions not in 2024

This changes it so that yield expressions are no longer allowed in the 2024 edition without a feature gate. We are currently only reserving the `gen` keyword in the 2024 edition, and not allowing anything else to be implicitly enabled by the edition.

In practice this doesn't have a significant difference since yield expressions can't really be used outside of coroutines or gen blocks, which have their own feature gates. However, it does affect what is accepted pre-expansion, and I would feel more comfortable not allowing yield expressions.

I believe the stabilization process for gen blocks or coroutines will not need to check the edition here, so this shouldn't ever be needed.

…parse-args-in-src-bootstrap-configure-py, r=onur-ozkan

test(configure): cover `parse_args` in `src/bootstrap/configure.py`

I was reading `src/bootstrap/configure.py` and `parse_args` function there seems complex. So I added some tests to cover it and prevent regressions.

…aw-parts, r=ibraheemdev

Generalize `NonNull::from_raw_parts` per ACP362

I did the raw pointers in rust-lang#125701, but apparently forgot `NonNull`.

cc rust-lang/libs-team#362

Update grammar in std::cell docs.

Using "having" in both the leading sentence and the bullets is unnecessary.
It makes it read as "it is only possible to have having several immutable...".

…nst_eval, r=compiler-errors

Consolidate type system const evaluation under `traits::evaluate_const`

Part of rust-lang#130704

Fixes rust-lang#128232
Fixes rust-lang#118545

Removes `ty::Const::{normalize_internal, eval_valtree}` and `InferCtxt::(try_)const_eval_resolve`, consolidating the associated logic into `evaluate_const` in `rustc_trait_selection`. This results in an API for `ty::Const` that is free of any normalization/evaluation functions that would be incorrect to use under `min_generic_const_args`/`associated_const_equality`/`generic_const_exprs` or, more generally, that would be incorrect to use in the presence of generic type system constants.

Moving this logic to `rustc_trait_selection` and out of `rustc_middle` is also a pre-requisite for ensuring that we do not evaluate constants whose where clauses do not hold.

From this point it should be relatively simple (hah) to implement more complex normalization of type system constants such as: checking wf'ness before invoking CTFE machinery, or being able to normalize const aliases that still refer to generic parameters.

r? `@compiler-errors`

…rcote

Make sure to ignore elided lifetimes when pointing at args for fulfillment errors

See the comment I left in the code.

---

If we have something like:

```
fn foo<'a, T: 'a + BoundThatIsNotSatisfied>() {}
```

And the user turbofishes just the type args:

```
foo::<()>();
```

Then if we try pointing at `()` (i.e. the type argument for `T`), we don't actually consider the possibility that the lifetimes may have been left out of the turbofish. We try indexing incorrectly into the HIR args, and bail on the suggestion.

Subtree update of `rust-analyzer`

r? `@ghost`