Handle unsized consts with type `str` in v0 symbol mangling
This PR fixes#116303 by handling consts with type `str` in v0 symbol mangling as partial support for unsized consts.
This PR is related to `#![feature(adt_const_params)]` (#95174) and `#![feature(unsized_const_params)]` (#128028).
r? ``@BoxyUwU``
Add str.as_str() for easy Deref to string slices
Working with `Box<str>` is cumbersome, because in places like `iter.filter()` it can end up being `&Box<str>` or even `&&Box<str>`, and such type doesn't always get auto-dereferenced as expected.
Dereferencing such box to `&str` requires ugly syntax like `&**boxed_str` or `&***boxed_str`, with the exact amount of `*`s.
`Box<str>` is [not easily comparable with other string types](https://github.com/rust-lang/rust/pull/129852) via `PartialEq`. `Box<str>` won't work for lookups in types like `HashSet<String>`, because `Borrow<String>` won't take types like `&Box<str>`. OTOH `set.contains(s.as_str())` works nicely regardless of levels of indirection.
`String` has a simple solution for this: the `as_str()` method, and `Box<str>` should too.
Bump stage0 to beta-2024-09-22 and rustfmt to nightly-2024-09-22
I'm doing this to apply the changes to version sorting (https://github.com/rust-lang/rustfmt/pull/6284) that have occurred since rustfmt last upgraded (and a few other miscellaneous changes, like changes to expression overflowing: https://github.com/rust-lang/rustfmt/pull/6260). Eagerly updating rustfmt and formatting-the-world will ideally move some of the pressure off of the beta bump which will happen at the beginning of the next release cycle.
You can verify this is correct by checking out the changes, reverting the last commit, reapplying them, and diffing the changes:
```
git fetch git@github.com:compiler-errors/rust.git bump
git checkout -b bump FETCH_HEAD
git reset --hard HEAD~5
./x.py fmt --all
git diff FETCH_HEAD
# ignore the changes to stage0, and rustfmt.toml,
# and test file changes in rustdoc-js-std, run-make.
```
Or just take my word for it? Up to the reviewer.
r? release
interpret: remove outdated FIXME
The rule about `repr(C)` types with compatible fields got removed from the ABI compat docs before they landed, so this FIXME here is no longer correct. (So this is basically a follow-up to https://github.com/rust-lang/rust/pull/130185, doing some more cleanup around deciding not to guarantee ABI compatibility for structurally compatible `repr(C)` types.)
Refactor fd read/write
This PR passed the responsibility of reading to user supplied buffer and dest place to each implementation of ``FileDescription::read/write/pread/pwrite``.
This is part of #3665.
Mark `char::make_ascii_uppercase` and `char::make_ascii_lowercase` as const.
Relevant tracking issue: #130698
The `make_ascii_uppercase` and `make_ascii_lowercase` methods in `char` should be marked "const."
With the stabilisation of [`const_mut_refs`](https://github.com/rust-lang/rust/issues/57349/), this simply requires adding the `const` specifier to the function signatures.
fix rustc_nonnull_optimization_guaranteed docs
As far as I can tell, even back when this was [added](https://github.com/rust-lang/rust/pull/60300) it never *enabled* any optimizations. It just indicates that the FFI compat lint should accept those types for NPO.
Rollup of 5 pull requests
Successful merges:
- #130648 (move enzyme flags from general cargo to rustc-specific cargo)
- #130650 (Fixup Apple target's description strings)
- #130664 (Generate line numbers for non-rust code examples as well)
- #130665 (Prevent Deduplication of `LongRunningWarn`)
- #130669 (tests: Test that `extern "C" fn` ptrs lint on slices)
r? `@ghost`
`@rustbot` modify labels: rollup
tests: Test that `extern "C" fn` ptrs lint on slices
This seems to have slipped past the `improper_ctypes_definitions` lint at some point. I found similar tests but not one with this exact combination, so test the semi-unique combination.
Prevent Deduplication of `LongRunningWarn`
Fixes#118612
As mention in the issue, `LongRunningWarn` is meant to be repeated multiple times.
Therefore, this PR stores a unique number in every instance of `LongRunningWarn` so that it's not hashed into the same value and omitted by the deduplication mechanism.
Fixup Apple target's description strings
Noticed this inconsistency in how the Apple target's had their new descriptions written while looking at https://github.com/rust-lang/rust/pull/130614, and figured it was easy enough to fixup shortly. I think prefixing every OS with `Apple` is clearer, especially for less known ones like `visionOS` and `watchOS`; so that's what was done here along with making the architecture names more consistent and then some other small tweaks.
~~r? `@thomcc~~`
cc `@madsmtm`
rustc_llvm: adapt to flattened CLI args in LLVM
This changed in
llvm/llvm-project@e190d074a0. I decided to stick with more duplication between the ifdef blocks to make the code easier to read for the next two years before we can plausibly drop LLVM 19.
`@rustbot` label: +llvm-main
try-job: x86_64-msvc
rustc_expand: remember module `#[path]`s during expansion
During invocation collection, if a module item parsed from a `#[path]` attribute needed a second pass after parsing, its path wouldn't get added to the file path stack, so cycle detection broke. This checks the `#[path]` in such cases, so that it gets added appropriately. I think it should work identically to the case for external modules that don't need a second pass, but I'm not 100% sure.
Fixes#97589
Fix anon const def-creation when macros are involved take 2
Fixes#130321
There were two cases that #129137 did not handle correctly:
- Given a const argument `Foo<{ bar!() }>` in which `bar!()` expands to `N`, we would visit the anon const and then visit the `{ bar() }` expression instead of visiting the macro call. This meant that we would build a def for the anon const as `{ bar!() }` is not a trivial const argument as `bar!()` is not a path.
- Given a const argument `Foo<{ bar!() }>` is which `bar!()` expands to `{ qux!() }` in which `qux!()` expands to `N`, it should not be considered a trivial const argument as `{{ N }}` has two pairs of braces. If we only looked at `qux`'s expansion it would *look* like a trivial const argument even though it is not. We have to track whether we have "unwrapped" a brace already when recursing into the expansions of `bar`/`qux`/any macro
r? `@camelid`
