...eports
and remove the feature gate that silenced the lint

...and lint

This allows the standard library to be compiled even with `download-rustc` enabled.
Which means it's no longer a requirement to compile `rustc` in order to compile `std`.
Signed-off-by: onur-ozkan <work@onurozkan.dev>

Signed-off-by: onur-ozkan <work@onurozkan.dev>

...et` like map API

...d" assertion ICE
See <rust-lang#128622>.

PR rust-lang#128581 introduced an assertion that all builtin attributes are
actually checked via `CheckAttrVisitor` and aren't accidentally usable
on completely unrelated HIR nodes. Unfortunately, the check had
correctness problems.
The match on attribute path segments looked like
```rust,ignore
[sym::should_panic] => /* check is implemented */
match BUILTIN_ATTRIBUTE_MAP.get(name) {
 // checked below
 Some(BuiltinAttribute { type_: AttributeType::CrateLevel, .. }) => {}
 Some(_) => {
 if !name.as_str().starts_with("rustc_") {
 span_bug!(
 attr.span,
 "builtin attribute {name:?} not handled by `CheckAttrVisitor`"
 )
 }
 }
 None => (),
}
```
However, it failed to account for edge cases such as an attribute whose:
1. path segments *starts* with a builtin attribute such as
 `should_panic`
2. which does not start with `rustc_`, and
3. is also an `AttributeType::Normal` attribute upon registration with
 the builtin attribute map
These conditions when all satisfied cause the span bug to be issued for e.g.
`#[should_panic::skip]` because the `[sym::should_panic]` arm is not matched (since it's
`[sym::should_panic, sym::skip]`).
See <rust-lang#128622>.

...t, r=compiler-errors
turn `invalid_type_param_default` into a `FutureReleaseErrorReportInDeps`
`````@rust-lang/types````` I assume the plan is still to disallow this? It has been a future-compat lint for a long time, seems ripe to go for hard error.
However, turns out that outright removing it right now would lead to [tons of crater regressions](rust-lang#127655 (comment)), so for now this PR just makes this future-compat lint show up in cargo's reports, so people are warned when they use a dependency that is affected by this.
Fixes rust-lang#27336 by removing the feature gate (so there's no way to silence the lint even on nightly)
CC rust-lang#36887 

...ct_with_derive, r=nnethercote
built-in derive: remove BYTE_SLICE_IN_PACKED_STRUCT_WITH_DERIVE hack and lint
Fixes rust-lang#107457 by turning the lint into a hard error. The lint has been shown in future breakage reports since Rust 1.69 (released in April 2023).
Let's see (via crater) if enough time has passed since rust-lang#104429, and unicode-org/icu4x#2834 has propagated far enough to let us make this a hard error.
Cc ``@nnethercote`` ``@Manishearth``

...k-Simulacrum
force compiling std from source if modified
This allows the standard library to be compiled even with `download-rustc` enabled. Which means it's no longer a requirement to compile `rustc` in order to compile `std`.
Ref. rust-lang#127322 (comment).
Blocker for rust-lang#122709.

Implement cursors for `BTreeSet`
Tracking issue: rust-lang#107540
This is a straightforward wrapping of the map API, except that map's `CursorMut` does not make sense, because there is no value to mutate. Hence, map's `CursorMutKey` is wrapped here as just `CursorMut`, since it's unambiguous for sets and we don't normally speak of "keys". On the other hand, I can see some potential for confusion with `CursorMut` meaning different things in each module. I'm happy to take suggestions to improve that.
r? ````@Amanieu````

...lacrum
Add test for updating enum discriminant through pointer
Closes rust-lang#122600 

...cote
Do not fire unhandled attribute assertion on multi-segment `AttributeType::Normal` attributes with builtin attribute as first segment
### The Problem
In rust-lang#128581 I introduced an assertion to check that all builtin attributes are actually checked via
`CheckAttrVisitor` and aren't accidentally usable on completely unrelated HIR nodes.
Unfortunately, the assertion had correctness problems as revealed in rust-lang#128622.
The match on attribute path segments looked like
```rs,ignore
// Normal handler
[sym::should_panic] => /* check is implemented */
// Fallback handler
[name, ..] => match BUILTIN_ATTRIBUTE_MAP.get(name) {
 // checked below
 Some(BuiltinAttribute { type_: AttributeType::CrateLevel, .. }) => {}
 Some(_) => {
 if !name.as_str().starts_with("rustc_") {
 span_bug!(
 attr.span,
 "builtin attribute {name:?} not handled by `CheckAttrVisitor`"
 )
 }
 }
 None => (),
}
```
However, it failed to account for edge cases such as an attribute whose:
1. path segments *starts* with a segment matching the name of a builtin attribute such as `should_panic`, and
2. the first segment's symbol does not start with `rustc_`, and
3. the matched builtin attribute is also of `AttributeType::Normal` attribute type upon registration with the builtin attribute map.
These conditions when all satisfied cause the span bug to be issued for e.g.
`#[should_panic::skip]` because the `[sym::should_panic]` arm is not matched (since it's
`[sym::should_panic, sym::skip]`).
### Proposed Solution
This PR tries to remedy that by adjusting all normal/specific handlers to not match exactly on a single segment, but instead match a prefix segment.
i.e.
```rs,ignore
// Normal handler, notice the `, ..` rest pattern
[sym::should_panic, ..] => /* check is implemented */
// Fallback handler
[name, ..] => match BUILTIN_ATTRIBUTE_MAP.get(name) {
 // checked below
 Some(BuiltinAttribute { type_: AttributeType::CrateLevel, .. }) => {}
 Some(_) => {
 if !name.as_str().starts_with("rustc_") {
 span_bug!(
 attr.span,
 "builtin attribute {name:?} not handled by `CheckAttrVisitor`"
 )
 }
 }
 None => (),
}
```
### Review Remarks
This PR contains 2 commits:
1. The first commit adds a regression test. This will ICE without the `CheckAttrVisitor` changes.
2. The second commit adjusts `CheckAttrVisitor` assertion logic. Once this commit is applied, the test should no longer ICE and produce the expected bless stderr.
Fixes rust-lang#128622.
r? ``@nnethercote`` (since you reviewed rust-lang#128581)