Require sanitizers be enabled for asan_odr_windows.rs
Issue Details:
The `asan_odr_windows.rs` test is failing on AArch64 Windows, as sanitizers aren't supported on that platform.
Fix Details:
Apply the correct "need sanitizer" requirements to the test.
chore: delete unused ui/auxiliary crates
It appears that all the tests that used it have been moved to tests/ui/editions/ (or elsewhere) already.
r? `````@jieyouxu`````
Don't FCW assoc consts in patterns
Fixes#140447
See comment in added test. We could also check that the anon const is a const arg by looking at the HIR. I'm not sure that's necessary though 🤔 The only consts that are evaluated "for the type system" are const args (which *should* get FCWs) and const patterns (which cant be anon consts afaik).
chore: edit and move tests
I deleted `ui/non-copyable-void.rs`: added in ab4105d9e8 to test that "nonconstructable" enums are "noncopyable", but these properties are not correlated anymore.
Second commit is kinda messy because I moved/edited/renamed some files at the same time, but I deleted nothing there.
transmutability: ensure_sufficient_stack when answering query
Based on #140380.
Fixes#118860. The compile time was addressed earlier, this merely addresses stack overflow part of the issue.
r? `@jswrenn` `@joshlf`
Issue an error when using `no_mangle` on language items
This pull requests adds the code to issue an error or a warning when using `no_mangle` on language items. This should detail why the `undefined symbol` error is issued for the code described in #139923.
The pull request adds two ui tests, one testing the error and the other one the warning.
I would love some feedback here, as I am not sure that the error and warning are issues using the right API.
Check bare function idents for non snake-case name
This PR adds the check required to lint on bare function idents for non snake-case name.
Reported at #140089.
cc `@theemathas`
Don't allow flattened format_args in const.
Fixes https://github.com/rust-lang/rust/issues/139136
Fixes https://github.com/rust-lang/rust/issues/139621
We allow `format_args!("a")` in const, but don't allow any format_args with arguments in const, such as `format_args!("{}", arg)`.
However, we accidentally allow `format_args!("hello {}", "world")` in const, as it gets flattened to `format_args!("hello world")`.
This also applies to panic in const.
This wasn't supposed to happen. I added protection against this in the format args flattening code, ~~but I accidentally marked a function as const that shouldn't have been const~~ but this was removed in https://github.com/rust-lang/rust/pull/135139.
This is a breaking change. The crater found no breakage, however.
This breaks things like:
```rust
const _: () = if false { panic!("a {}", "a") };
```
and
```rust
const F: std::fmt::Arguments<'static> = format_args!("a {}", "a");
```
add suggestion on how to add a panic breakpoint
Co-authored-by: Pat Pannuto <pat.pannuto@gmail.com>
delete no_mangle from ui/panic-handler/panic-handler-wrong-location test
issue an error for the usage of #[no_mangle] on internal language items
delete the comments
add newline
rephrase note
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
update error not to leak implementation details
delete no_mangle_span
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
delete commented code
The previous implementation was inconsistent about transitions that
apply for an init byte. For example, when answering a query, an init
byte could use corresponding init transition. Init byte could also use
uninit transition, but only when the corresponding init transition was
absent. This behaviour was incompatible with DFA union construction.
Define an uninit transition to match an uninit byte only and update
implementation accordingly. To describe that `Tree::uninit` is valid
for any value, build an automaton that accepts any byte value.
Additionally, represent byte ranges uniformly as a pair of integers to
avoid special case for uninit byte.
Extend the alignment check to borrows
The current alignment check does not include checks for creating misaligned references from raw pointers, which is now added in this patch.
When inserting the check we need to be careful with references to field projections (e.g. `&(*ptr).a`), in which case the resulting reference must be aligned according to the field type and not the type of the pointer.
r? `@saethlin`
cc `@RalfJung,` after our discussion in #134424
Most notably, the `FIXME` for suboptimal printing of `use` groups in
`tests/ui/macros/stringify.rs` is fixed. And all other test output
changes result in pretty printed output being closer to the original
formatting in the source code.
Implement the internal feature `cfg_target_has_reliable_f16_f128`
Support for `f16` and `f128` is varied across targets, backends, and backend versions. Eventually we would like to reach a point where all backends support these approximately equally, but until then we have to work around some of these nuances of support being observable.
Introduce the `cfg_target_has_reliable_f16_f128` internal feature, which provides the following new configuration gates:
* `cfg(target_has_reliable_f16)`
* `cfg(target_has_reliable_f16_math)`
* `cfg(target_has_reliable_f128)`
* `cfg(target_has_reliable_f128_math)`
`reliable_f16` and `reliable_f128` indicate that basic arithmetic for the type works correctly. The `_math` versions indicate that anything relying on `libm` works correctly, since sometimes this hits a separate class of codegen bugs.
These options match configuration set by the build script at [1]. The logic for LLVM support is duplicated as-is from the same script. There are a few possible updates that will come as a follow up.
The config introduced here is not planned to ever become stable, it is only intended to replace the build scripts for `std` tests and `compiler-builtins` that don't have any way to configure based on the codegen backend.
MCP: https://github.com/rust-lang/compiler-team/issues/866
Closes: https://github.com/rust-lang/compiler-team/issues/866
[1]: 555e1d0386/library/std/build.rs (L84-L186)
---
The second commit makes use of this config to replace `cfg_{f16,f128}{,_math}` in `library/`. I omitted providing a `cfg(bootstrap)` configuration to keep things simpler since the next beta branch is in two weeks.
try-job: aarch64-gnu
try-job: i686-msvc-1
try-job: test-various
try-job: x86_64-gnu
try-job: x86_64-msvc-ext2
Move inline asm check to typeck, properly handle aliases
Pull `InlineAsmCtxt` down to `rustc_hir_typeck`, and instead of using things like `Ty::is_copy`, use the `InferCtxt`-aware methods. To fix https://github.com/rust-lang/trait-system-refactor-initiative/issues/189, we also add a `try_structurally_resolve_*` call to `expr_ty`.
r? lcnr
Do not compute type_of for impl item if impl where clauses are unsatisfied
Consider the following code:
```rust
trait Foo {
fn call(self) -> impl Send;
}
trait Nested {}
impl<T> Foo for T
where
T: Nested,
{
fn call(self) -> impl Sized {
NotSatisfied.call()
}
}
struct NotSatisfied;
impl Foo for NotSatisfied {
fn call(self) -> impl Sized {
todo!()
}
}
```
In `impl Foo for NotSatisfied`, we need to prove that the RPITIT is well formed. This requires proving the item bound `<NotSatisfied as Foo>::RPITIT: Send`. Normalizing `<NotSatisfied as Foo>::RPITIT: Send` assembles two impl candidates, via the `NotSatisfied` impl and the blanket `T` impl. We end up computing the `type_of` for the blanket impl even if `NotSatisfied: Nested` where clause does not hold.
This type_of query ends up needing to prove that its own `impl Sized` RPIT satisfies `Send`, which ends up needing to compute the hidden type of the RPIT, which is equal to the return type of `NotSatisfied.call()`. That ends up in a query cycle, since we subsequently try normalizing that return type via the blanket impl again!
In the old solver, we don't end up computing the `type_of` an impl candidate if its where clauses don't hold, since this select call would fail before confirming the projection candidate:
d7ea436a02/compiler/rustc_trait_selection/src/traits/project.rs (L882)
This PR makes the new solver more consistent with the old solver by adding a call to `try_evaluate_added_goals` after regstering the impl predicates, which causes us to bail before computing the `type_of` for impls if the impl definitely doesn't apply.
r? lcnr
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/185
allow deref patterns to move out of boxes
This adds a case to lower deref patterns on boxes using a built-in deref instead of a `Deref::deref` or `DerefMut::deref_mut` call: if `deref!(inner): Box<T>` is matching on place `place`, the inner pattern `inner` now matches on `*place` rather than a temporary. No longer needing to call a method also means it won't borrow the scrutinee in match arms. This allows for bindings in `inner` to move out of `*place`.
For comparison with box patterns, this uses the same MIR lowering but different THIR. Consequently, deref patterns on boxes are treated the same as any other deref patterns in match exhaustiveness analysis. Box patterns can't quite be implemented in terms of deref patterns until exhaustiveness checking for deref patterns is implemented (I'll open a PR for exhaustiveness soon!).
Tracking issue: #87121
r? ``@Nadrieril``
Rollup of 7 pull requests
Successful merges:
- #140056 (Fix a wrong error message in 2024 edition)
- #140220 (Fix detection of main function if there are expressions around it)
- #140249 (Remove `weak` alias terminology)
- #140316 (Introduce `BoxMarker` to improve pretty-printing correctness)
- #140347 (ci: clean more disk space in codebuild)
- #140349 (ci: use aws codebuild for the `dist-x86_64-linux` job)
- #140379 (rustc-dev-guide subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
Async drop codegen
Async drop implementation using templated coroutine for async drop glue generation.
Scopes changes to generate `async_drop_in_place()` awaits, when async droppable objects are out-of-scope in async context.
Implementation details:
https://github.com/azhogin/posts/blob/main/async-drop-impl.md
New fields in Drop terminator (drop & async_fut). Processing in codegen/miri must validate that those fields are empty (in full version async Drop terminator will be expanded at StateTransform pass or reverted to sync version). Changes in terminator visiting to consider possible new successor (drop field).
ResumedAfterDrop messages for panic when coroutine is resumed after it is started to be async drop'ed.
Lang item for generated coroutine for async function async_drop_in_place. `async fn async_drop_in_place<T>()::{{closure0}}`.
Scopes processing for generate async drop preparations. Async drop is a hidden Yield, so potentially async drops require the same dropline preparation as for Yield terminators.
Processing in StateTransform: async drops are expanded into yield-point. Generation of async drop of coroutine itself added.
Shims for AsyncDropGlueCtorShim, AsyncDropGlue and FutureDropPoll.
```rust
#[lang = "async_drop"]
pub trait AsyncDrop {
#[allow(async_fn_in_trait)]
async fn drop(self: Pin<&mut Self>);
}
impl Drop for Foo {
fn drop(&mut self) {
println!("Foo::drop({})", self.my_resource_handle);
}
}
impl AsyncDrop for Foo {
async fn drop(self: Pin<&mut Self>) {
println!("Foo::async drop({})", self.my_resource_handle);
}
}
```
First async drop glue implementation re-worked to use the same drop elaboration code as for sync drop.
`async_drop_in_place` changed to be `async fn`. So both `async_drop_in_place` ctor and produced coroutine have their lang items (`AsyncDropInPlace`/`AsyncDropInPlacePoll`) and shim instances (`AsyncDropGlueCtorShim`/`AsyncDropGlue`).
```
pub async unsafe fn async_drop_in_place<T: ?Sized>(_to_drop: *mut T) {
}
```
AsyncDropGlue shim generation uses `elaborate_drops::elaborate_drop` to produce drop ladder (in the similar way as for sync drop glue) and then `coroutine::StateTransform` to convert function into coroutine poll.
AsyncDropGlue coroutine's layout can't be calculated for generic T, it requires known final dropee type to be generated (in StateTransform). So, `templated coroutine` was introduced here (`templated_coroutine_layout(...)` etc).
Such approach overrides the first implementation using mixing language-level futures in https://github.com/rust-lang/rust/pull/121801.
Remove `weak` alias terminology
I find the "weak" alias terminology to be quite confusing. It implies the existence of "strong" aliases (which do not exist) and I'm not really sure what about weak aliases is "weak". I much prefer "free alias" as the term. I think it's much more obvious what it means as "free function" is a well defined term that already exists in rust.
It's also a little confusing given "weak alias" is already a term in linker/codegen spaces which are part of the compiler too. Though I'm not particularly worried about that as it's usually very obvious if you're talking about the type system or not lol. I'm also currently trying to write documentation about aliases and it's somewhat awkward/confusing to be talking about *weak* aliases, when I'm not really sure what the basis for that as the term actually *is*.
I would also be happy to just find out there's a nice meaning behind calling them "weak" aliases :-)
r? `@oli-obk`
maybe we want a types MCP to decide on a specific naming here? or maybe we think its just too late to go back on this naming decision ^^'
Implement a lint for implicit autoref of raw pointer dereference - take 2
*[t-lang nomination comment](https://github.com/rust-lang/rust/pull/123239#issuecomment-2727551097)*
This PR aims at implementing a lint for implicit autoref of raw pointer dereference, it is based on #103735 with suggestion and improvements from https://github.com/rust-lang/rust/pull/103735#issuecomment-1370420305.
The goal is to catch cases like this, where the user probably doesn't realise it just created a reference.
```rust
pub struct Test {
data: [u8],
}
pub fn test_len(t: *const Test) -> usize {
unsafe { (*t).data.len() } // this calls <[T]>::len(&self)
}
```
Since #103735 already went 2 times through T-lang, where they T-lang ended-up asking for a more restricted version (which is what this PR does), I would prefer this PR to be reviewed first before re-nominating it for T-lang.
----
Compared to the PR it is as based on, this PR adds 3 restrictions on the outer most expression, which must either be:
1. A deref followed by any non-deref place projection (that intermediate deref will typically be auto-inserted)
2. A method call annotated with `#[rustc_no_implicit_refs]`.
3. A deref followed by a `addr_of!` or `addr_of_mut!`. See bottom of post for details.
There are several points that are not 100% clear to me when implementing the modifications:
- ~~"4. Any number of automatically inserted deref/derefmut calls." I as never able to trigger this. Am I missing something?~~ Fixed
- Are "index" and "field" enough?
----
cc `@JakobDegen` `@WaffleLapkin`
r? `@RalfJung`
try-job: dist-various-1
try-job: dist-various-2
Support for `f16` and `f128` is varied across targets, backends, and
backend versions. Eventually we would like to reach a point where all
backends support these approximately equally, but until then we have to
work around some of these nuances of support being observable.
Introduce the `cfg_target_has_reliable_f16_f128` internal feature, which
provides the following new configuration gates:
* `cfg(target_has_reliable_f16)`
* `cfg(target_has_reliable_f16_math)`
* `cfg(target_has_reliable_f128)`
* `cfg(target_has_reliable_f128_math)`
`reliable_f16` and `reliable_f128` indicate that basic arithmetic for
the type works correctly. The `_math` versions indicate that anything
relying on `libm` works correctly, since sometimes this hits a separate
class of codegen bugs.
These options match configuration set by the build script at [1]. The
logic for LLVM support is duplicated as-is from the same script. There
are a few possible updates that will come as a follow up.
The config introduced here is not planned to ever become stable, it is
only intended to replace the build scripts for `std` tests and
`compiler-builtins` that don't have any way to configure based on the
codegen backend.
MCP: https://github.com/rust-lang/compiler-team/issues/866
Closes: https://github.com/rust-lang/compiler-team/issues/866
[1]: 555e1d0386/library/std/build.rs (L84-L186)
