| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Takes crash tests from #135039, #103899, #91985 and #105299 and turns them into ui tests
|
|
|
|
|
|
r=compiler-errors
Stabilize `feature(trait_upcasting)`
This feature was "done" for a while now, I think it's finally time to stabilize it! Stabilization report: https://github.com/rust-lang/rust/pull/134367#issuecomment-2545839841.
cc reference PR: https://github.com/rust-lang/reference/pull/1622.
Closes #65991 (tracking issue), closes #89460 (the lint is no longer future incompat).
r? compiler-errors
|
|
fix tail call checks wrt `#[track_caller]`
Only check the caller + disallow caller having the attribute.
fixes #134336
r? `@compiler-errors`
<sub>apparently there were no tests for `#[track_caller]` before... ooops</sub>
|
|
|
|
disallow `repr()` on invalid items
fixes https://github.com/rust-lang/rust/issues/129606
fixes https://github.com/rust-lang/rust/issues/132391
Disallows `repr()` (so a repr with no arguments) on items where that won't ever make sense.
Also this generates an error when `repr` is used on a trait method and the `fn_align` feature is not enabled. Looks like that was missed here:
https://github.com/rust-lang/rust/pull/110313/files
Which first accepts the align attribute on trait methods.
r? `@compiler-errors`
cc `@jdonszelmann` who claimed https://github.com/rust-lang/rust/issues/132391 and generally has been working on attributes
|
|
only check the caller + disallow caller having the attr.
|
|
Remove unnecessary layout assertions for object-safe receivers
The soundness of `DispatchFromDyn` relies on the fact that, like all other built-in marker-like layout traits (e.g. `Sized`, `CoerceUnsized`), the guarantees that they enforce in *generic* code via traits will result in assumptions that we can rely on in codegen.
Specifically, `DispatchFromDyn` ensures that we end up with a receiver that is a valid pointer type, and its implementation validity recursively ensures that the ABI of that pointer type upholds the `Scalar` or `ScalarPair` representation for sized and unsized pointees, respectively.
The check that this layout guarantee holds for arbitrary, possibly generic receiver types that also may exist in possibly impossible-to-instantiate where clauses is overkill IMO, and leads to several ICEs due to the fact that computing layouts before monomorphization is going to be fallible at best.
This PR removes the check altogether, since it just exists as a sanity check from very long ago, 6f2a161b1bbe6234188d6cfb3cabddef1e6ef20f.
Fixes #125810
Fixes #90110
This PR is an alternative to #136195. cc `@adetaylor.` I didn't realize in that PR that the layout checks that were being modified were simply *sanity checks*, rather than being actually necessary for soundness.
|
|
Report generic mismatches when calling bodyless trait functions
Don't know if there's an open issue for this. Just happened to notice this when working in that area.
The awkward extra spans added to the diagnostics of some tests (e.g. `trait-with-missing-associated-type-restriction`) is consistent with what happens for normal functions. Should probably be removed since that span doesn't seem to note anything useful.
First and third commit are both cleanups removing some unnecessary work. Second commit has the actual fix.
fixes #135124
|
|
Check Sizedness of return type in WF
Still need to clean this up a bit. This should fix https://github.com/rust-lang/trait-system-refactor-initiative/issues/150.
r? lcnr
|
|
Enable more tests on Windows
As part of the discussion of https://github.com/rust-lang/compiler-team/issues/822 on Zulip, it was mentioned that problems with the i686-pc-windows-gnu target may have resulted in tests being disabled on Windows.
So in this PR, I've ripped out all our `//@ ignore-windows` directives, then re-added all the ones that are definitely required based on the outcome of try-builds, and in some cases I've improved the justification or tightened the directives to `//@ ignore-msvc` or ignoring specific targets.
|
|
|
|
|
|
|
|
|
|
Use proper type when applying deref adjustment in const
When applying a deref adjustment to some type `Wrap<T>` which derefs to `T`, we were checking that `T: ~const Deref`, not `Wrap<T>: ~const Deref` like we should have been.
r? project-const-traits
Fixes #136273
Fixes #135210 -- I just deleted the test since the regression test is uninteresting
|
|
|
|
and remove `ty::Const::try_to_scalar` because it becomes redundant
|
|
|
|
add two old crash tests
This is for #108248 and #132826.
|
|
- `check-pass` test for a MRE of #135020
- fail test for #135138
- switch to `TooGeneric` for checking CMSE fn signatures
- switch to `TooGeneric` for compute `SizeSkeleton` (for transmute)
- fix broken tests
|
|
|
|
|
|
Shunpoco:issue-133117-ICE-never-false-edge-start-block, r=Nadrieril
Fix ICE-133117: multiple never-pattern arm doesn't have false_edge_start_block
Fixes #133117 , and close fixes #133063 , fixes #130779
In order to fix ICE-133117, at first I needed to tackle to ICE-133063 (this fixed 130779 as well).
### ICE-133063 and ICE-130779
This ICE is caused by those steps:
1. An arm has or-pattern, and all of the sub-candidates are never-pattern
2. In that case, all sub-candidates are removed in remove_never_subcandidates(). So the arm (candidate) has no sub-candidate.
3. In the current implementation, if there is no sub-candidate, the function assigns `pre_binding_block` into the candidate ([here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_build/src/builder/matches/mod.rs#L2002-L2004)). However, otherwise_block should be assigned to the candidate as well, because the otherwise_block is unwrapped in multiple place (like in lower_match_tree()). As a result, it causes the panic.
I simply added the same block as pre_binding_block into otherwise_block, but I'm wondering if there is a better block to assign to otherwise_block (is it ok to assign the same block into pre_binding and otherwise?)
### ICE-133117
This is caused by those steps:
1. There are two arms, both are or-pattern and each has one match-pair (in the test code, both are `(!|!)`), and the second arm has a guard.
2. In match_candidate() for the first arm, it expands the second arm’s sub-candidates as well ([here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_build/src/builder/matches/mod.rs#L1800-L1805)). As a result, the root candidate of the second arm is not evaluated/modified in match_candidate(). So a false_edge_start_block is not assigned to the candidate.
3. merge_trivial_subcandidates() is called against the candidate for the second arm. It just returns immediately because the candidate has a guard. So a flase_edge_start_block is not assigned to the candidate also in this function.
4. remove_never_subcandidates() is called against the candidate. Since all sub-candidates are never-pattern. they are removed.
5. In lower_match_tree(), since there is no sub-candidate for the candidate, the candidate itself is evaluated in visit_leave_rev ([here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_build/src/builder/matches/mod.rs#L1532)). Because the candidate has no false_edge_start_block, it causes the panic.
So I modified the order of if blocks in merge_trivial_subcandidates() to assign a false_edge_start_block if the candidate doesn't have.
|
|
Remove unnecessary assertion for reference error
Fixes #135341
From comment: https://github.com/rust-lang/rust/issues/135341#issuecomment-2594430504
r? ``@oli-obk``
|
|
Location-sensitive polonius prototype: endgame
This PR sets up the naive location-sensitive analysis end-to-end, and replaces the location-insensitive analysis. It's roughly all the in-progress work I wanted to land for the prototype, modulo cleanups I still want to do after the holidays, or the polonius debugger, and so on.
Here, we traverse the localized constraint graph, have to deal with kills and time-traveling (👌), and record that as loan liveness for the existing scope and active loans computations.
Then the near future looks like this, especially if the 2025h1 project goal is accepted:
- gradually bringing it up to completion
- analyzing and fixing the few remaining test failures
- going over the *numerous* fixmes in this prototype (one of which is similar to a hang on one test's millions and millions of constraints)
- trying to see how to lower the impact of the lack of NLL liveness optimization on diagnostics, and their categorization of local variables and temporaries (the vast majority of blessed expectations differences), as well as the couple ICEs trying to find an NLL constraint to blame for errors.
- dealing with the theoretical weakness around kills, conflating reachability for the two TCS, etc that is described ad nauseam in the code.
- switching the compare mode to the in-tree implementation, and blessing the diagnostics
- apart from the hang, it's not catastrophically slower on our test suite, so then we can try to enable it on CI
- checking crater, maybe trying to make it faster :3, etc.
I've tried to gradually introduce this PR's work over 4 commits, because it's kind of subtle/annoying, and Niko/I are not completely convinced yet. That one comment explaining the situation is maybe 30% of the PR 😓. Who knew that spacetime reachability and time-traveling could be mind bending.
I kinda found this late and the impact on this part of the computation was a bit unexpected to us. A bit more care/thought will be needed here. I've described my plan in the comments though. In any case, I believe we have the current implementation is a conservative approximation that shouldn't result in unsoundness but false positives at worst. So it feels fine for now.
r? ``@jackh726``
---
Fixes #127628 -- which was a assertion triggered for a difference in loan computation between NLLs and the location-insensitive analysis. That doesn't exist anymore so I've removed this crash test.
|
|
|
|
|
|
Signed-off-by: Shunpoco <tkngsnsk313320@gmail.com>
|
|
|
|
|
|
|
|
|
|
Project to `TyKind::Error` when there are unconstrained non-lifetime (ty/const) impl params
It splits the `enforce_impl_params_are_constrained` function into lifetime/non-lifetime, and queryfies the latter. We can then use the result of the latter query (`Result<(), ErrorGuaranteed>`) to intercept projection and constrain the projected type to `TyKind::Error`, which ensures that we leak no ty or const vars to places that don't expect them, like `normalize_erasing_regions`.
The reason we split `enforce_impl_params_are_constrained` into two parts is because we only error for *lifetimes* if the lifetime ends up showing up in any of the associated types of the impl (e.g. we allow `impl<'a> Foo { type Assoc = (); }`). However, in order to compute the `type_of` query for the anonymous associated type of an RPITIT, we need to do trait solving (in `query collect_return_position_impl_trait_in_trait_tys`). That would induce cycles. Luckily, it turns out for lifetimes we don't even care about if they're unconstrained, since they're erased in all contexts that we are trying to fix ICEs. So it's sufficient to keep this check separated out of the query.
I think this is a bit less invasive of an approach compared to #127973. The major difference between this PR and that PR is that we queryify the check instead of merging it into the `explicit_predicates_of` query, and we use the result to taint just projection goals, rather than trait goals too. This doesn't require a lot of new tracking in `ItemCtxt` and `GenericPredicates`, and it also seems to not require any other changes to typeck like that PR did.
Fixes #123141
Fixes #125874
Fixes #126942
Fixes #127804
Fixes #130967
r? oli-obk
|
|
|
|
|
|
|
|
Avoid ICE in borrowck
Provide a fallback in `best_blame_constraint` when `find_constraint_paths_between_regions` doesn't have a result. This code is due a rework to avoid the letf-over `unwrap()`, but avoids the ICE caused by the repro.
Fix #133252.
|
|
Make `ty::Error` implement all auto traits
I have no idea what's up with the crashes test I fixed--I really don't want to look into it since it has to do something with borrowck and multiple layers of opaques. I think the underlying idea of allowing error types to implement all auto traits is justified though.
Fixes #134796
Fixes #131050
r? lcnr
|
|
[macro_metavar_expr_concat] Fix #128346
Fix #128346
Fix #131393
The syntax is invalid in both issues so I guess that theoretically the compiler should have aborted early.
This PR tries to fix a local problem but let me know if there are better options.
cc `@petrochenkov` if you are interested
|
|
|
|
|
|
Provide a fallback in `best_blame_constraint` when `find_constraint_paths_between_regions` doesn't have a result. This code is due a rework to avoid the letf-over `unwrap()`, but avoids the ICE caused by the repro.
Fix #133252.
|
|
Remove a duplicated check that doesn't do anything anymore.
fixes #134005
This code didn't actually `lub` the type of the previous expressions, but just the current type over and over again. Changing it to using the actual expression type does not change anything either, so may as well remove the entire loop.
|
|
|
|
cleanup region handling: add `LateParamRegionKind`
The second commit is to enable a split between `BoundRegionKind` and `LateParamRegionKind`, by avoiding `BoundRegionKind` where it isn't necessary.
The third comment then adds `LateParamRegionKind` to avoid having the same late-param region for separate bound regions. This fixes #124021.
r? `@compiler-errors`
|
|
|
|
|
|
|
