| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
(cherry picked from commit c5ec1b8bc57797d3a01aa1258139fcfb3c629628)
|
|
(cherry picked from commit 926e874fd1dccc208bf63db7a4288adf46caa3c3)
|
|
(cherry picked from commit ff54c801f0c1552941bda472df992e9f9be25f33)
|
|
|
|
(cherry picked from commit 24c2c075cc2216af8868809fdd68c9da8466c327)
|
|
(cherry picked from commit 1ee189cde53a4cecd3e8811d6ffe983676a70c7b)
|
|
|
|
|
|
Do not attempt to commute comparison and cast to codegen discriminants
The general algorithm to compute a discriminant is:
```
relative_tag = tag - niche_start
is_niche = relative_tag <= (ule) relative_max
discr = if is_niche {
cast(relative_tag) + niche_variants.start()
} else {
untagged_variant
}
```
We have an optimization branch which attempts to merge the addition and the subtraction by commuting them with the cast. We currently get this optimization wrong.
This PR takes the easiest and safest way: remove the optimization, and let LLVM handle it. (Perf may not agree with that course of action :sweat_smile:)
There may be a less invasive solution, but I don't have the necessary knowledge of LLVM semantics to find it. Cranelift has the same optimization, which should be handled similarly.
cc `@nikic` and `@bjorn3` if you have a better solution.
Fixes https://github.com/rust-lang/rust/issues/110128
|
|
Remove some unneeded imports / qualified paths
Continuation of #105537.
|
|
compiler-errors:reformulate-point_at_expr_source_of_inferred_type, r=oli-obk
Reformulate `point_at_expr_source_of_inferred_type` to be more accurate
Be more accurate when deducing where along the several usages of a binding it is constrained to be some type that is incompatible with an expectation.
This also renames the method to `note_source_of_type_mismatch_constraint` because I prefer that name, though I guess I can revert that. (Also drive-by rename `note_result_coercion` -> `suggest_coercing_result_via_try_operator`, because it's suggesting, not noting!)
This PR is (probably?) best reviewed per commit, but it does regress a bit only to fix it later on, so it could also be reviewed as a whole if that makes the final results more clear.
r? `@estebank`
|
|
|
|
Remove all but one of the spans in `BoundRegionKind::BrAnon`
There are only three places where `BoundRegionKind::BrAnon` uses `Some(span)` instead of `None`. Two of them are easy to remove, which this PR does.
r? ```@jackh726```
|
|
Assemble `Unpin` candidates specially for generators in new solver
Fixes compiler-errors/next-solver-hir-issues#16
r? ``@lcnr``
|
|
don't uniquify regions when canonicalizing
uniquifying causes a bunch of issues, most notably it causes `AliasEq(<?x as Trait<'a>>::Assoc, <?x as Trait<'a>>::Assoc)` to result in ambiguity because both `normalizes-to` paths result in ambiguity and substs equate should trivially succeed but doesn't because we uniquified `'a` to two different regions.
I originally added uniquification to make it easier to deal with requirement 6 from the dev-guide: https://rustc-dev-guide.rust-lang.org/solve/trait-solving.html#requirements
> ### 6. Trait solving must be (free) lifetime agnostic
>
> Trait solving during codegen should have the same result as during typeck. As we erase
> all free regions during codegen we must not rely on them during typeck. A noteworthy example
> is special behavior for `'static`.
cc https://github.com/rust-lang/rustc-dev-guide/pull/1671
Relying on regions being identical may cause ICE during MIR typeck, but even without this PR we can end up relying on that as type inference vars can resolve to types which contain an identical region. Let's land this and deal with any ICE that crop up as we go. Will look at this issue again before stabilization.
r? ```@compiler-errors```
|
|
r=compiler-errors
Improve safe transmute error reporting
This patch updates the error reporting when Safe Transmute is not possible between 2 types by including the reason.
Also, fix some small bugs that occur when computing the `Answer` for transmutability.
|
|
Move most ui-fulldeps tests to ui/
Same rationale as https://github.com/rust-lang/rust/pull/109770, they don't actually need a stage 2 build.
This increases the limit for the UI directory because otherwise it was annoying to be constantly moving files into subdirectories when I fixed a test; https://github.com/rust-lang/rust/pull/109873 makes up for it.
cc https://github.com/rust-lang/rust/pull/109770, https://github.com/rust-lang/rust/pull/109874
|
|
|
|
|
|
The `std` test straightforwardly can't work without file descriptors;
#99417 tracks moving it out of tests/ui.
`issue-13560.rs` requires the target to support dynamic linking.
`extern-mod-syntax` is interesting. The original test was added to check
if `extern mod` could be parsed correctly and used `extern mod std` and
an import:
https://github.com/rust-lang/rust/commit/138dc3048af36f0a20f857542c357fe8df563013#diff-73700e1e851b7a37bc92174635dab726124c82e5bfabbbc45b4a3c2e8e14fadd
At some point `std::json::Object` was moved out of std to an unstable
rustc-only `extras` crate, and rather than just changing the import it
got changed to use the unstable crate. When `extras` was removed, people
assumed the test was meant to also test rustc_private and changed it to
another unstable crate rather than using something in std.
This changes the test to remove the `rustc_private` import, to allow it
to work properly when cross-compiling.
|
|
They pass fine. Only tests that required `extern crate rustc_*` or were
marked `ignore-stage1` have been keep in fulldeps.
|
|
|
|
|
|
This patch updates the error reporting when Safe Transmute is not
possible between 2 types by including the reason.
Also, fix some small bugs that occur when computing the `Answer` for
transmutability.
|
|
Only emit alignment checks if we have a panic_impl
Fixes https://github.com/rust-lang/rust/issues/109996
r? `@bjorn3` because you commented that this situation could impact you as well
|
|
dead-code-lint: de-dup multiple unused assoc functions
Fixes #109600
Prior art: #97853
|
|
Added diagnostic for pin! macro in addition to Box::pin if Unpin isn't implemented
I made a PR earlier, but accidentally renamed a branch and that deleted the PR... sorry for the duplicate
Currently, if an operation on `Pin<T>` is performed that requires `T` to implement `Unpin`, the diagnostic suggestion is to use `Box::pin` ("note: consider using `Box::pin`").
This PR suggests pin! as well, as that's another valid way of pinning a value, and avoids a heap allocation. Appropriate diagnostic suggestions were included to highlight the difference in semantics (local pinning for pin! vs non-local for Box::pin).
Fixes #109964
|
|
Check for body owner fallibly in error reporting
Sometimes the "body id" we use for an obligation cause is not actually a body owner, like when we're doing WF checking on items.
Fixes #110157
|
|
|
|
|
|
- remove unused (pun intentional) `continue`
- improve wording with assoc items in general
|
|
|
|
Erase lifetimes above `ty::INNERMOST` when probing ambiguous types
Turns out that `TyCtxt::replace_escaping_bound_vars_uncached` only erases bound vars exactly at `ty::INNERMOST`, and not everything above. This regresses the suggestions for non-lifetime binders, but oh well, I don't really care about those.
Fixes #110052
|
|
with repect to other dead code lints
|
|
Tweak output for 'add line' suggestion
Closes #108174
|
|
r=wesleywiser
Preserve argument indexes when inlining MIR
We store argument indexes on VarDebugInfo. Unlike the previous method of relying on the variable index to know whether a variable is an argument, this survives MIR inlining.
We also no longer check if var.source_info.scope is the outermost scope. When a function gets inlined, the arguments to the inner function will no longer be in the outermost scope. What we care about though is whether they were in the outermost scope prior to inlining, which we know by whether we assigned an argument index.
Fixes #83217
I considered using `Option<NonZeroU16>` instead of `Option<u16>` to store the index. I didn't because `TypeFoldable` isn't implemented for `NonZeroU16` and because it looks like due to padding, it currently wouldn't make any difference. But I indexed from 1 anyway because (a) it'll make it easier if later it becomes worthwhile to use a `NonZeroU16` and because the arguments were previously indexed from 1, so it made for a smaller change.
This is my first PR on rust-lang/rust, so apologies if I've gotten anything not quite right.
|
|
|
|
|
|
call
|
|
|
|
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #109810 (Replace rustdoc-ui/{c,z}-help tests with a stable run-make test )
- #110035 (fix: ensure bad `#[test]` invocs retain correct AST)
- #110089 (sync::mpsc: synchronize receiver disconnect with initialization)
- #110103 (Report overflows gracefully with new solver)
- #110122 (Fix x check --stage 1 when download-ci-llvm=false)
- #110133 (Do not use ImplDerivedObligationCause for inherent impl method error reporting)
- #110135 (Revert "Don't recover lifetimes/labels containing emojis as character literals")
- #110235 (Fix `--extend-css` option)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
implemented
|
|
Revert "Don't recover lifetimes/labels containing emojis as character literals"
Reverts PR #108031 per https://github.com/rust-lang/rust/pull/109754#issuecomment-1490452045
Fixes (doesnt close until beta backported) #109746
This reverts commit e3f9db5fc319c6d8eee5d47d216ea6a426070c41.
This reverts commit 98b82aedba3f3f581e89df54352914b27f42c6f7.
This reverts commit 380fa264132ad481e73cbbf0f3a0feefd99a1d78.
|
|
Do not use ImplDerivedObligationCause for inherent impl method error reporting
We were constructing a `TraitRef` out of impl substs, for an *inherent* impl that has no corresponding trait. Instead of doing that, let's construct a meaningful obligation cause code, and instead adjust the error reporting machinery to handle that correctly.
Fixes #110131
cc #106702, which introduced this regression
|
|
Report overflows gracefully with new solver
avoid reporting overflows as ambiguity errors, so that the error message is clearer.
r? ```@lcnr```
|
