Remove region from adjustments
It's not necessary to store this region, because it's only used in THIR and MemCat/ExprUse, both of which already basically only deal with erased regions anyways.
force-recompile library changes on download-rustc="if-unchanged"
This makes the download-rustc="if-unchanged" option more functional and useful for library developers.
Implements the second item from [this tracking issue](https://github.com/rust-lang/rust/issues/131744).
Rename `rustc_abi::Abi` to `BackendRepr`
Remove the confabulation of `rustc_abi::Abi` with what "ABI" actually means by renaming it to `BackendRepr`, and rename `Abi::Aggregate` to `BackendRepr::Memory`. The type never actually represented how things are passed, as that has to have `PassMode` considered, at minimum, but rather it just is how we represented some things to the backend. This conflation arose because LLVM, the primary backend at the time, would lower certain IR forms using certain ABIs. Even that only somewhat was true, as it broke down when one ventured significantly afield of what is described by the System V AMD64 ABI either by using different architectures, ABI-modifying IR annotations, the same architecture **with different ISA extensions enabled**, or other... unexpected delights.
Unfortunately both names are still somewhat of a misnomer right now, as people have written code for years based on this misunderstanding. Still, their original names are even moreso, and for better or worse, this backend code hasn't received as much maintenance as the rest of the compiler, lately. Actually arriving at a correct end-state will simply require us to disentangle a lot of code in order to fix, much of it pointlessly repeated in several places. Thus this is not an "actual fix", just a way to deflect further misunderstandings.
rustdoc: make doctest span tweak a 2024 edition change
Fixes#132203
This is a compatibility hack, because I think the new behavior is better. When an A `include_str!` B, and B `include_str!` C, the path to C should be resolved relative to B, not A. That's how `include!` itself works, so that's how `include_str!` with should work.
Fix directives for lint-non-snake-case-crate
This test fails on targets without unwinding or with `--target-rustcflags=-Cpanic=abort` because the proc macro was compiled as the target, not the host. Some targets were explicitly disabled to pass CI, but these directives are more general.
* `needs-dynamic-linking` is self explanatory
* `force-host` for proc macros
* `no-prefer-dynamic` is apparently also used for proc macros
Note that `needs-unwind` can also be useful for situations other than proc macros where unwinding is necessary.
r? `@jieyouxu`
try-job: test-various
Use Hacker's Delight impl in `i64::midpoint` instead of wide `i128` impl
This PR switches `i64::midpoint` and (`isize::midpoint` where `isize == i64`) to using our Hacker's Delight impl instead of wide `i128` implementation.
As LLVM seems to be outperformed by the complexity of signed 128-bits number compared to our Hacker's Delight implementation.[^1]
It doesn't seems like it's an improvement for the other sizes[^2], so we let them with the wide implementation.
[^1]: https://rust.godbolt.org/z/ravE75EYj
[^2]: https://rust.godbolt.org/z/fzr171zKh
r? libs
Rc/Arc: don't leak the allocation if drop panics
Currently, when the last `Rc<T>` or `Arc<T>` is dropped and the destructor of `T` panics, the allocation will be leaked. This leak is unnecessary since the data cannot be (safely) accessed again and `Box` already deallocates in this case, so let's do the same for `Rc` and `Arc`, too.
Rollup of 12 pull requests
Successful merges:
- #131375 (compiler: apply clippy::clone_on_ref_ptr for CI)
- #131520 (Mark `str::is_char_boundary` and `str::split_at*` unstably `const`.)
- #132119 (Hack out effects support for old solver)
- #132194 (Collect item bounds for RPITITs from trait where clauses just like associated types)
- #132216 (correct LLVMRustCreateThinLTOData arg types)
- #132233 (Split `boxed.rs` into a few modules)
- #132266 (riscv-soft-abi-with-float-features.rs: adapt for LLVM 20)
- #132270 (clarified doc for `std::fs::OpenOptions.truncate()`)
- #132284 (Remove my ping for rustdoc/clean/types.rs)
- #132293 (Remove myself from mentions inside `tests/ui/check-cfg` directory)
- #132312 (Delete `tests/crashes/23707.rs` because it's flaky)
- #132313 (compiletest: Rename `command-list.rs` to `directive-list.rs`)
r? `@ghost`
`@rustbot` modify labels: rollup
Split `boxed.rs` into a few modules
I wanted to add an impl for `Box<_>`, but was quickly discouraged by the 3K file. This splits off a couple bits, making it at least a bit more manageable.
r? ````@workingjubilee```` (I think you are not bothered by refactorings like this?)
correct LLVMRustCreateThinLTOData arg types
`LLVMRustCreateThinLTOData` defined in rust as
```rust
pub fn LLVMRustCreateThinLTOData(
Modules: *const ThinLTOModule,
NumModules: c_uint,
PreservedSymbols: *const *const c_char,
PreservedSymbolsLen: c_uint,
) -> Option<&'static mut ThinLTOData>;
```
but in cpp as
```cpp
extern "C" LLVMRustThinLTOData *
LLVMRustCreateThinLTOData(LLVMRustThinLTOModule *modules, int num_modules,
const char **preserved_symbols, int num_symbols) {
```
(note `c_unit` vs `int` types). Let it be actually `size_t`.
Also fixes return type of `LLVMRustDIBuilderCreateOpLLVMFragment` to uint64_t as other similar functions around, which should be correct, i assume.
Collect item bounds for RPITITs from trait where clauses just like associated types
We collect item bounds from trait where clauses for *associated types*, i.e. this:
```rust
trait Foo
where
Self::Assoc: Send
{
type Assoc;
}
```
Becomes this:
```rust
trait Foo {
type Assoc: Send;
}
```
Today, with RPITITs/AFIT and return-type notation, we don't do that, i.e.:
```rust
trait Foo where Self::method(..): Send {
fn method() -> impl Sized;
}
fn is_send(_: impl Send) {}
fn test<T: Foo>() {
is_send(T::method());
}
```
...which fails on nightly today.
Turns out it's super easy to fix this, and we just need to use the `associated_type_bounds` lowering function in `explicit_item_bounds_with_filter`, which has that logic baked in.
Mark `str::is_char_boundary` and `str::split_at*` unstably `const`.
Tracking issues: #131516, #131518
First commit implements `const_is_char_boundary`, second commit implements `const_str_split_at` (which depends on `const_is_char_boundary`)
~~I used `const_eval_select` for `is_char_boundary` since there is a comment about optimizations that would theoretically not happen with the simple `const`-compatible version (since `slice::get` is not `const`ifiable) cc #84751. I have not checked if this code difference is still required for the optimization, so it might not be worth the code complication, but 🤷.~~
This changes `str::split_at_checked` to use a new private helper function `split_at_unchecked` (copied from `split_at_mut_unchecked`) that does pointer stuff instead of `get_unchecked`, since that is not currently `const`ifiable due to using the `SliceIndex` trait.
Lint against getting pointers from immediately dropped temporaries
Fixes#123613
## Changes:
1. New lint: `dangling_pointers_from_temporaries`. Is a generalization of `temporary_cstring_as_ptr` for more types and more ways to get a temporary.
2. `temporary_cstring_as_ptr` is removed and marked as renamed to `dangling_pointers_from_temporaries`.
3. `clippy::temporary_cstring_as_ptr` is marked as renamed to `dangling_pointers_from_temporaries`.
4. Fixed a false positive[^fp] for when the pointer is not actually dangling because of lifetime extension for function/method call arguments.
5. `core::cell::Cell` is now `rustc_diagnostic_item = "Cell"`
## Questions:
- [ ] Instead of manually checking for a list of known methods and diagnostic items, maybe add some sort of annotation to those methods in library and check for the presence of that annotation? https://github.com/rust-lang/rust/pull/128985#issuecomment-2318714312
## Known limitations:
### False negatives[^fn]:
See the comments in `compiler/rustc_lint/src/dangling.rs`
1. Method calls that are not checked for:
- `temporary_unsafe_cell.get()`
- `temporary_sync_unsafe_cell.get()`
2. Ways to get a temporary that are not recognized:
- `owning_temporary.field`
- `owning_temporary[index]`
3. No checks for ref-to-ptr conversions:
- `&raw [mut] temporary`
- `&temporary as *(const|mut) _`
- `ptr::from_ref(&temporary)` and friends
[^fn]: lint **should** be emitted, but **is not**
[^fp]: lint **should not** be emitted, but **is**
Rollup of 4 pull requests
Successful merges:
- #131391 (Stabilize `isqrt` feature)
- #132248 (rustc_transmute: Directly use types from rustc_abi)
- #132252 (compiler: rename LayoutS to LayoutData)
- #132253 (Known-bug test for `keyword_idents` lint not propagating to other files)
r? `@ghost`
`@rustbot` modify labels: rollup
Known-bug test for `keyword_idents` lint not propagating to other files
Known-bug test for `keyword_idents` lint not propagating to other files when configured via attribute (#132218).
compiler: rename LayoutS to LayoutData
Bid `LayoutS` goodbye because it looks like a typo.
`LayoutS` is the last of the types that use the "`{TypeName}` is the interned type, `{TypeName}S` is the backing data that is interned" convention. This is pretty confusing to those not intimately familiar with the history of rustc's names for its types over time, and doubly so now that there are no other examples in the tree. Abolish this convention.
I.e. the following situation:
```
fn foo() {
mod bar {
fn qux() {
// Prelude path here (e.g. macro use prelude or extern prelude).
}
}
}
```
Those were previously unresolved, because, in order to support `self` and `super` properly, since #15148 we do not ascend block paths when there is a module in between, but only crate def maps register preludes, not block def maps, and we can't change this because block def map prelude can always be overridden by another block. E.g.
```
fn foo() {
struct WithTheSameNameAsPreludeItem;
{
WithTheSameNameAsPreludeItem
}
}
```
Here `WithTheSameNameAsPreludeItem` refer to the item from the top block, but if we would register prelude items in each block the child block would overwrite it incorrectly.
