| Age | Commit message (Collapse) | Author | Lines |
|---|
|
r=oli-obk
Fix trait upcasting to dyn type with no principal when there are projections
#126660 (which I had originally authored, lol) had a subtle bug that is the moral equivalent of #114036, which is that when upcasting from `dyn Principal<Projection = Ty> + AutoTrait` to `dyn AutoTrait`, we were dropping the trait ref for `Principal` but not its projections (if there were any).
With debug assertions enabled, this triggers the assertion I luckily added in a2a0cfe82563146325674b8d437f9f9f6e703703, but even without debug assertions this is a logical bug since we had a dyn type with just a projection bound but no principal, so it caused a type mismatch.
This does not need an FCP because this should've been covered by the FCP in #126660, but we just weren't testing a case when casting from a `dyn` type with projections 😸
Fixes #139418
r? ````@oli-obk```` (or anyone)
|
|
compiler-errors:non-lifetime-binder-diag-hir-wf-check, r=oli-obk
Don't construct preds w escaping bound vars in `diagnostic_hir_wf_check`
See comment inline.
Fixes #139330
r? oli-obk
|
|
compiler: report error when trait object type param reference self
Fixes #139082.
Emits an error when `Self` is found in the projection bounds of a trait
object. In type aliases, `Self` has no meaning, so `type A = &'static
dyn B` where `trait B = Fn() -> Self` will expands to `type A = &'static
Fn() -> Self` which is illegal, causing the region solver to bail out
when hitting the uninferred Self.
r? ````@compiler-errors```` ````@fee1-dead````
|
|
Tell LLVM about impossible niche tags
I was trying to find a better way of emitting discriminant calculations, but sadly had no luck.
So here's a fairly small PR with the bits that did seem worth bothering:
1. As the [`TagEncoding::Niche` docs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_abi/enum.TagEncoding.html#variant.Niche) describe, it's possible to end up with a dead value in the input that's not already communicated via the range parameter attribute nor the range load metadata attribute. So this adds an `llvm.assume` in non-debug mode to tell LLVM about that. (That way it can tell that the sides of the `select` have disjoint possible values.)
2. I'd written a bunch more tests, or at least made them parameterized, in the process of trying things out, so this checks in those tests to hopefully help future people not trip on the same weird edge cases, like when the tag type is `i8` but yet there's still a variant index and discriminant of `258` which doesn't fit in that tag type because the enum is really weird.
|
|
Make error message for missing fields with `..` and without `..` more consistent
When `..` is not present, we say "missing field `bar` in initializer", but when it is present we say "missing mandatory field `bar`". I don't see why the primary error message should change, b/c the root cause is the same.
Let's harmonize these error messages and instead use a label to explain that `..` is required b/c it's not defaulted.
r? estebank
|
|
Implement overflow for infinite implied lifetime bounds
Not a great error message, but better than a hang
Fixes #138665
Fixes #102966
Fixes #115407
r? lcnr
|
|
|
|
Fixes #139445.
The additional errors aren't great but the first one is still good and
it's the most important, and imperfect errors are better than ICEing.
|
|
This can happen when invalid syntax is passed to a declarative macro. We
shouldn't be too strict about the token stream position once the parser
has rejected the invalid syntax.
Fixes #139248.
|
|
|
|
|
|
|
|
targets
also mention the MSVC alignment issue in platform-support.md
|
|
Do not visit whole crate to compute `lints_that_dont_need_to_run`.
This allows to reuse the computed lint levels instead of re-visiting the whole crate.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use `const_eval_select!()` macro to enable contract checking only at
runtime. The existing contract logic relies on closures,
which are not supported in constant functions.
This commit also removes one level of indirection for ensures clauses,
however, it currently has a spurious warning message when the bottom
of the function is unreachable.
|
|
This catches some silly notes emitted by rustc, which should ideally be fixed
|
|
|
|
Those that didn't previously preserved kind are now marked as not requiring annotations to keep the previous behavior.
Also, do not lose diagnostics with an empty message.
|
|
|
|
add sret handling for scalar autodiff
r? `@oli-obk`
Fixing one of the todo's which I left in my previous batching PR.
This one handles sret for scalar autodiff. `sret` mostly shows up when we try to return a lot of scalar floats.
People often start testing autodiff which toy functions which just use a few scalars as inputs and outputs, and those were the most likely to be affected by this issue. So this fix should make learning/teaching hopefully a bit easier.
Tracking:
- https://github.com/rust-lang/rust/issues/124509
|
|
Stop calling `source_span` query in significant drop order code
`source_span` is only meant for incremental tracking. I don't really think we need to highlight the whole drop impl span anyways; it can be quite large.
r? oli-obk
|
|
Remove support for `extern "rust-intrinsic"` blocks
Part of rust-lang/rust#132735
Looked manageable and there didn't appear to have been progress in the last two weeks,
so decided to give it a try.
|
|
Implement `super let`
Tracking issue: https://github.com/rust-lang/rust/issues/139076
This implements `super let` as proposed in #139080, based on the following two equivalence rules.
1. For all expressions `$expr` in any context, these are equivalent:
- `& $expr`
- `{ super let a = & $expr; a }`
2. And, additionally, these are equivalent in any context when `$expr` is a temporary (aka rvalue):
- `& $expr`
- `{ super let a = $expr; & a }`
So far, this experiment has a few interesting results:
## Interesting result 1
In this snippet:
```rust
super let a = f(&temp());
```
I originally expected temporary `temp()` would be dropped at the end of the statement (`;`), just like in a regular `let`, because `temp()` is not subject to temporary lifetime extension.
However, it turns out that that would break the fundamental equivalence rules.
For example, in
```rust
g(&f(&temp()));
```
the temporary `temp()` will be dropped at the `;`.
The first equivalence rule tells us this must be equivalent:
```rust
g({ super let a = &f(&temp()); a });
```
But that means that `temp()` must live until the last `;` (after `g()`), not just the first `;` (after `f()`).
While this was somewhat surprising to me at first, it does match the exact behavior we need for `pin!()`: The following _should work_. (See also https://github.com/rust-lang/rust/issues/138718)
```rust
g(pin!(f(&mut temp())));
```
Here, `temp()` lives until the end of the statement. This makes sense from the perspective of the user, as no other `;` or `{}` are visible. Whether `pin!()` uses a `{}` block internally or not should be irrelevant.
This means that _nothing_ in a `super let` statement will be dropped at the end of that super let statement. It does not even need its own scope.
This raises questions that are useful for later on:
- Will this make temporaries live _too long_ in cases where `super let` is used not in a hidden block in a macro, but as a visible statement in code like the following?
```rust
let writer = {
super let file = File::create(&format!("/home/{user}/test"));
Writer::new(&file)
};
```
- Is a `let` statement in a block still the right syntax for this? Considering it has _no_ scope of its own, maybe neither a block nor a statement should be involved
This leads me to think that instead of `{ super let $pat = $init; $expr }`, we might want to consider something like `let $pat = $init in $expr` or `$expr where $pat = $init`. Although there are also issues with these, as it isn't obvious anymore if `$init` should be subject to temporary lifetime extension. (Do we want both `let _ = _ in ..` and `super let _ = _ in ..`?)
## Interesting result 2
What about `super let x;` without initializer?
```rust
let a = {
super let x;
x = temp();
&x
};
```
This works fine with the implementation in this PR: `x` is extended to live as long as `a`.
While it matches my expectations, a somewhat interesting thing to realize is that these are _not_ equivalent:
- `super let x = $expr;`
- `super let x; x = $expr;`
In the first case, all temporaries in $expr will live at least as long as (the result of) the surrounding block.
In the second case, temporaries will be dropped at the end of the assignment statement. (Because the assignment statement itself "is not `super`".)
This difference in behavior might be confusing, but it _might_ be useful.
One might want to extend the lifetime of a variable without extending all the temporaries in the initializer expression.
On the other hand, that can also be expressed as:
- `let x = $expr; super let x = x;` (w/o temporary lifetime extension), or
- `super let x = { $expr };` (w/ temporary lifetime extension)
So, this raises these questions:
- Do we want to accept `super let x;` without initializer at all?
- Does it make sense for statements other than let statements to be "super"? An expression statement also drops temporaries at its `;`, so now that we discovered that `super let` basically disables that `;` (see interesting result 1), is there a use to having other statements without their own scope? (I don't think that's ever useful?)
## Interesting result 3
This works now:
```rust
super let Some(x) = a.get(i) else { return };
```
I didn't put in any special cases for `super let else`. This is just the behavior that 'naturally' falls out when implementing `super let` without thinking of the `let else` case.
- Should `super let else` work?
## Interesting result 4
This 'works':
```rust
fn main() {
super let a = 123;
}
```
I didn't put in any special cases for `super let` at function scope. I had expected the code to cause an ICE or other weird failure when used at function body scope, because there's no way to let the variable live as long as the result of the function.
This raises the question:
- Does this mean that this behavior is the natural/expected behavior when `super let` is used at function scope? Or is this just a quirk and should we explicitly disallow `super let` in a function body? (Probably the latter.)
---
The questions above do not need an answer to land this PR. These questions should be considered when redesigning/rfc'ing/stabilizing the feature.
|
|
Add new `PatKind::Missing` variants
To avoid some ugly uses of `kw::Empty` when handling "missing" patterns, e.g. in bare fn tys. Helps with #137978. Details in the individual commits.
r? ``@oli-obk``
|
|
|
|
The default s390x cpu(z10) does not have vector support. Setting
target-cpu at least to z13 enables vectorisation for s390x architecture
and makes the tests pass.
|
|
fix usage of `autodiff` macro with inner functions
This PR adds additional handling into the expansion step of the `std::autodiff` macro (in `compiler/rustc_builtin_macros/src/autodiff.rs`), which allows the macro to be applied to inner functions.
```rust
#![feature(autodiff)]
use std::autodiff::autodiff;
fn main() {
#[autodiff(d_inner, Forward, Dual, DualOnly)]
fn inner(x: f32) -> f32 {
x * x
}
}
```
Previously, the compiler didn't allow this due to only handling `Annotatable::Item` and `Annotatable::AssocItem` and missing the handling of `Annotatable::Stmt`. This resulted in the rather generic error
```
error: autodiff must be applied to function
--> src/main.rs:6:5
|
6 | / fn inner(x: f32) -> f32 {
7 | | x * x
8 | | }
| |_____^
error: could not compile `enzyme-test` (bin "enzyme-test") due to 1 previous error
```
This issue was originally reported [here](https://github.com/EnzymeAD/rust/issues/184).
Quick question: would it make sense to add a ui test to ensure there is no regression on this?
This is my first contribution, so I'm extra grateful for any piece of feedback!! :D
r? `@oli-obk`
Tracking issue for autodiff: #124509
|
|
|
|
|
|
Verify that the expanded `inline` and `rustc_autodiff` macros are not
duplicated.
|
|
|
|
r=jdonszelmann
Check if merged attributes list is empty in expr
Fixes #139373
In the example code, an [`UnrecognizedReprHint`](https://github.com/rust-lang/rust/blob/6b5ccfc87f59ab017032e430d4d358b4989735da/compiler/rustc_attr_parsing/src/attributes/repr.rs#L155) error is output, and the list of merged attributes becomes empty. This causes a [panic](https://github.com/rust-lang/rust/blob/6b5ccfc87f59ab017032e430d4d358b4989735da/compiler/rustc_ast_lowering/src/lib.rs#L618) to occur. So, it's necessary to check if merged attributes list is empty as other functions do.
ref: https://github.com/rust-lang/rust/blob/6b5ccfc87f59ab017032e430d4d358b4989735da/compiler/rustc_ast_lowering/src/lib.rs#L896
|
|
Prevent a test from seeing forbidden numbers in the rustc version
The final CHECK-NOT directive in this test was able to see past the end of the enclosing function, and find the substring `753` or `754` in the git hash in the rustc version number, causing false failures in CI whenever the git hash happens to contain those digits in sequence.
Adding an explicit check for `ret` prevents the CHECK-NOT directive from seeing past the end of the function.
---
Manually tested by adding `// CHECK-NOT: rustc` after the existing CHECK-NOT directives, and demonstrating that the new check prevents it from seeing the rustc version string.
|
|
|
|
|
|
The final CHECK-NOT directive in this test was able to see past the end of the
enclosing function, and find the substring 753 or 754 in the git hash in the
rustc version number, causing false failures in CI.
Adding an explicit check for `ret` prevents the CHECK-NOT directive from seeing
past the end of the function.
|
|
|
|
Update the minimum external LLVM to 19
With this change, we'll have stable support for LLVM 19 and 20.
For reference, the previous increase to LLVM 18 was #130487.
cc `@rust-lang/wg-llvm`
r? nikic
|
|
|
|
|
|
|
|
|
|
Implement `SliceIndex` for `ByteStr`
Implement `Index` and `IndexMut` for `ByteStr` in terms of `SliceIndex`. Implement it for the same types that `&[u8]` supports (a superset of those supported for `&str`, which does not have `usize` and `ops::IndexRange`).
At the same time, move compare and index traits to a separate file in the `bstr` module, to give it more space to grow as more functionality is added (e.g., iterators and string-like ops). Order the items in `bstr/traits.rs` similarly to `str/traits.rs`.
cc `@joshtriplett`
`ByteStr`/`ByteString` tracking issue: https://github.com/rust-lang/rust/issues/134915
|
