| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
Account for `for` lifetimes when constructing closure to see if dereferencing the return value would be valid.
Fix #125634, fix #124563.
|
|
Fixes <https://github.com/rust-lang/rust/issues/122587>
|
|
|
|
Account for things that optimize out in inlining costs
This updates the MIR inlining `CostChecker` to have both bonuses and penalties, rather than just penalties.
That lets us add bonuses for some things where we want to encourage inlining without risking wrapping into a gigantic cost. For example, `switchInt(const …)` we give an inlining bonus because codegen will actually eliminate the branch (and associated dead blocks) once it's monomorphized, so measuring both sides of the branch gives an unrealistically-high cost to it. Similarly, an `unreachable` terminator gets a small bonus, because whatever branch leads there doesn't actually exist post-codegen.
|
|
Fix assertion failure for some `Expect` diagnostics.
In #120699 I moved some code dealing with `has_future_breakage` earlier in `emit_diagnostic`. Issue #126521 identified a case where that reordering was invalid (leading to an assertion failure) for some `Expect` diagnostics.
This commit partially undoes the change, by moving the handling of unstable `Expect` diagnostics earlier again. This makes `emit_diagnostic` a bit uglier, but is necessary to fix the problem.
Fixes #126521.
r? ``@oli-obk``
|
|
|
|
In #120699 I moved some code dealing with `has_future_breakage` earlier
in `emit_diagnostic`. Issue #126521 identified a case where that
reordering was invalid (leading to an assertion failure) for some `Expect`
diagnostics.
This commit partially undoes the change, by moving the handling of
unstable `Expect` diagnostics earlier again. This makes
`emit_diagnostic` a bit uglier, but is necessary to fix the problem.
Fixes #126521.
|
|
|
|
Rollup of 3 pull requests
Successful merges:
- #126568 (mark undetermined if target binding in current ns is not got)
- #126577 (const_refs_to_static test and cleanup)
- #126584 (Do not ICE in privacy when type inference fails.)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Do not ICE in privacy when type inference fails.
Fixes https://github.com/rust-lang/rust/issues/122736
|
|
mark undetermined if target binding in current ns is not got
Fixes #126376
Fixes #126389
Add a branch to handle more cases...
r? `@petrochenkov`
|
|
Consistently use subtyping in method resolution
fixes #126062
An earlier version of this PR modified how we compute variance, but the root cause was an inconsistency between the usage of `eq` and `sub`, where we assumed that the latter passing implies the former will pass.
r? `@compiler-errors`
|
|
|
|
|
|
PR #121208 converted this from a `span_delayed_bug` to a `span_bug`
because nothing in the test suite caused execution to hit this path. But
now fuzzing has found a test case that does hit it. So this commit
converts it back to `span_delayed_bug` and adds the relevant test.
Fixes #126385.
|
|
|
|
|
|
Add `f16` and `f128` const eval for binary and unary operationations
Add const evaluation and Miri support for f16 and f128, including unary and binary operations. Casts are not yet included.
Fixes https://github.com/rust-lang/rust/issues/124583
r? ``@RalfJung``
|
|
Const eval negation was added. This test is now covered by Miri tests,
and merged into an existing UI test.
Fixes <https://github.com/rust-lang/rust/issues/124583>
|
|
Avoid ICES after reporting errors on erroneous patterns
fixes #109812
fixes #125914
fixes #124004
|
|
|
|
|
|
Previously, the implementation of `Tree::from_enum` incorrectly
treated enums with `Variants::Single` and `Variants::Multiple`
identically. This is incorrect for `Variants::Single` enums,
which delegate their layout to that of a variant with a particular
index (or no variant at all if the enum is empty).
This flaw manifested first as an ICE. `Tree::from_enum` attempted
to compute the tag of variants other than the one at
`Variants::Single`'s `index`, and fell afoul of a sanity-checking
assertion in `compiler/rustc_const_eval/src/interpret/discriminant.rs`.
This assertion is non-load-bearing, and can be removed; the routine
its in is well-behaved even without it.
With the assertion removed, the proximate issue becomes apparent:
calling `Tree::from_variant` on a variant that does not exist is
ill-defined. A sanity check the given variant has
`FieldShapes::Arbitrary` fails, and the analysis is (correctly)
aborted with `Err::NotYetSupported`.
This commit corrects this chain of failures by ensuring that
`Tree::from_variant` is not called on variants that are, as far as
layout is concerned, nonexistent. Specifically, the implementation
of `Tree::from_enum` is now partitioned into three cases:
1. enums that are uninhabited
2. enums for which all but one variant is uninhabited
3. enums with multiple inhabited variants
`Tree::from_variant` is now only invoked in the third case. In the
first case, `Tree::uninhabited()` is produced. In the second case,
the layout is delegated to `Variants::Single`'s index.
Fixes #125811
|
|
Delegation: fix ICE on recursive delegation
fixes https://github.com/rust-lang/rust/issues/124347
r? `@petrochenkov`
|
|
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #124731 (Add translation support by mdbook-i18n-helpers to bootstrap)
- #125168 (Match ergonomics 2024: align implementation with RFC)
- #125925 (Don't trigger `unsafe_op_in_unsafe_fn` for deprecated safe fns)
- #125987 (When `derive`ing, account for HRTB on `BareFn` fields)
- #126045 (check_expr_struct_fields: taint context with errors if struct definit…)
- #126048 (Fix typos in cargo-specifics.md)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Remove the `ty` field from type system `Const`s
Fixes #125556
Fixes #122908
Part of the work on `adt_const_params`/`generic_const_param_types`/`min_generic_const_exprs`/generally making the compiler nicer. cc rust-lang/project-const-generics#44
Please review commit-by-commit otherwise I wasted a lot of time not just squashing this into a giant mess (and also it'll be SO much nicer because theres a lot of fluff changes mixed in with other more careful changes if looking via File Changes
---
Why do this?
- The `ty` field keeps causing ICEs and weird behaviour due to it either being treated as "part of the const" or it being forgotten about leading to ICEs.
- As we move forward with `adt_const_params` and a potential `min_generic_const_exprs` it's going to become more complex to actually lower the correct `Ty<'tcx>`
- It muddles the idea behind how we check `Const` arguments have the correct type. By having the `ty` field it may seem like we ought to be relating it when we relate two types, or that its generally important information about the `Const`.
- Brings the compiler more in line with `a-mir-formality` as that also tracks the type of type system `Const`s via `ConstArgHasType` bounds in the env instead of on the `Const` itself.
- A lot of stuff is a lot nicer when you dont have to pass around the type of a const lol. Everywhere we construct `Const` is now significantly nicer :sweat_smile:
See #125671's description for some more information about the `ty` field
---
General summary of changes in this PR:
- Add `Ty` to `ConstKind::Value` as otherwise there is no way to implement `ConstArgHasType` to ensure that const arguments are correctly typed for the parameter when we stop creating anon consts for all const args. It's also just incredibly difficult/annoying to thread the correct `Ty` around to a bunch of ctfe functions otherwise.
- Fully implement `ConstArgHasType` in both the old and new solver. Since it now has no reliance on the `ty` field it serves its originally intended purpose of being able to act as a double check that trait vs impls have correctly typed const parameters. It also will now be able to be responsible for checking types of const arguments to parameters under `min_generic_const_exprs`.
- Add `Ty` to `mir::Const::Ty`. I dont have a great understanding of why mir constants are setup like this to be honest. Regardless they need to be able to determine the type of the const and the easiest way to make this happen was to simply store the `Ty` along side the `ty::Const`. Maybe we can do better here in the future but I'd have to spend way more time looking at everywhere we use `mir::Const`.
- rustdoc has its own `Const` which also has a `ty` field. It was relatively easy to remove this.
---
r? `@lcnr` `@compiler-errors`
|
|
check_expr_struct_fields: taint context with errors if struct definit…
Taint errors while checking `struct { field: 1 }` below if struct definition has duplicated fields so that we don't pass it to const eval.
fixes #125842, fixes #124464, fixes #124552
```rust
struct Struct {
field: Option<u8>,
field: u8,
}
static STATIC: Struct = Struct {
field: 1,
};
pub fn main() {}
```
(This was #125947 but i messed something up, sorry)
r? ``@compiler-errors``
|
|
|
|
malformed
|
|
resolve: mark it undetermined if single import is not has any bindings
- Fixes #124490
- Fixes #125013
This issue arises from incorrect resolution updates, for example:
```rust
mod a {
pub mod b {
pub mod c {}
}
}
use a::*;
use b::c;
use c as b;
fn main() {}
```
1. In the first loop, binding `(root, b)` is refer to `root::a::b` due to `use a::*`.
1. However, binding `(root, c)` isn't defined by `use b::c` during this stage because `use c as b` falls under the `single_imports` of `(root, b)`, where the `imported_module` hasn't been computed yet. This results in marking the `path_res` for `b` as `Indeterminate`.
2. Then, the `imported_module` for `use c as b` will be recorded.
2. In the second loop, `use b::c` will be processed again:
1. Firstly, it attempts to find the `path_res` for `(root, b)`.
2. It will iterate through the `single_imports` of `use b::c`, encounter `use c as b`, attempt to resolve `c` in `root`, and ultimately return `Err(Undetermined)`, thus passing the iterator.
3. Use the binding `(root, b)` -> `root::a::b` introduced by `use a::*` and ultimately return `root::a::b` as the `path_res` of `b`.
4. Then define the binding `(root, c)` -> `root::a::b::c`.
3. Then process `use c as b`, update the resolution for `(root, b)` to refer to `root::a::b::c`, ultimately causing inconsistency.
In my view, step `2.2` has an issue where it should exit early, similar to the behavior when there's no `imported_module`. Therefore, I've added an attribute called `indeterminate` to `ImportData`. This will help us handle only those single imports that have at least one determined binding.
r? ``@petrochenkov``
|
|
Fix ICE caused by ignoring EffectVars in type inference
Fixes #119830
r? ```@matthiaskrgr```
|
|
|
|
|
|
|
|
Signed-off-by: Andrew Wock <ajwock@gmail.com>
|
|
|
|
I think that this test is supposed to be a treereduced version of
122903-1.rs, but is actually identical.
|
|
This test reproduces a rustc ICE. Unfortunately, the changes to lifetime
elision mask the original ICE bug by making this function signature
illegal. However, by simplifying the signature we can regain the
original ICE.
|
|
|
|
Don't suggest turning non-char-literal exprs of ty `char` into string literals
Fixes #125595.
Fixes #125081.
r? estebank (#122217) or compiler
|
|
|
|
the meantime
|
|
|
