| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
consider item bounds for non-yet-defined opaque types
Based on rust-lang/rust#140405.
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/182
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/196
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/205
there's some jank here, see https://github.com/rust-lang/trait-system-refactor-initiative/issues/229
## Design
If the self type is an inference variable which has been sub-unified with am opaque type, we need to incompletely guide inference to avoid breakage.
In this case, we
- look at the item bounds of all sub-unified opaque types, and
- blanket impls which do not constrain the self type
Even if there are applicable candidates, we always force their certainty to be `Maybe`, so they will always have to be reproven once we've constrained the inference variable.
This is a bit iffy, see the added tests.
r? `@BoxyUwU`
|
|
Skip typeck for items w/o their own typeck context
Skip items which forward typeck to their ancestor.
Should remove some potential but unnecessary typeck query waits, hence might improve performance for the parallel frontend.
Thanks to `@ywxt` for a fix suggestion
Fixes rust-lang/rust#141951
|
|
|
|
Trim paths less in MIR dumping
With this PR, the paths MIR dump filters and that are printed at the start of a dump file are no longer trimmed. They don't include the crate that is being compiled, however.
|
|
r=jdonszelmann,ralfjung,traviscross
Implement `#[rustc_align_static(N)]` on `static`s
Tracking issue: https://github.com/rust-lang/rust/issues/146177
```rust
#![feature(static_align)]
#[rustc_align_static(64)]
static SO_ALIGNED: u64 = 0;
```
We need a different attribute than `rustc_align` because unstable attributes are tied to their feature (we can't have two unstable features use the same unstable attribute). Otherwise this uses all of the same infrastructure as `#[rustc_align]`.
r? `@traviscross`
|
|
|
|
We need a different attribute than `rustc_align` because unstable attributes are
tied to their feature (we can't have two unstable features use the same
unstable attribute). Otherwise this uses all of the same infrastructure
as `#[rustc_align]`.
|
|
rename erase_regions to erase_and_anonymize_regions
I find it consistently confusing that `erase_regions` does more than replacing regions with `'erased`. it also makes some code look real goofy to be writing manual folders to erase regions with a comment saying "we cant use erase regions" :> or code that re-calls erase_regions on types with regions already erased just to anonymize all the bound regions.
r? lcnr
idk how i feel about the name being almost twice as long now
|
|
|
|
|
|
const-eval: disable pointer fragment support
This fixes https://github.com/rust-lang/rust/issues/146291 by disabling pointer fragment support for const-eval. I want to properly fix this eventually, but won't get to it in the next few weeks, so this is an emergency patch to prevent the buggy implementation from landing on stable. The beta cutoff is on Sep 12th so if this PR lands after that, we'll need a backport.
|
|
Port limit attributes to the new attribute parsing infrastructure
Doesn't pass tests, to be rebased on https://github.com/rust-lang/rust/pull/145792 which will solve that
r? `@fmease`
|
|
|
|
eagerly compute `sub_unification_table` again
Previously called `sub_relations`. We still only using them for diagnostics right now. This mostly reverts rust-lang/rust#119989. Necessary for type inference guidance due to not-yet defined opaque types, cc https://github.com/rust-lang/trait-system-refactor-initiative/issues/182.
We could use them for cycle detection in generalization and it seems desirable to do so in the future. However, this is unsound with the old trait solver as its cache does not track these `sub_unification_table` in any way.
We now properly track the `sub_unification_table` when canonicalizing so using them in the new solver is totally sound and the performance impact is far more manageable than I thought back in rust-lang/rust#119989.
r? `@compiler-errors`
|
|
Some `rustc_middle` cleanups
Minor improvements I found while looking through this code.
r? `@BoxyUwU`
|
|
Migrate more things in the new solver to specific `DefId`s
Continuation of https://github.com/rust-lang/rust/pull/145377. I migrated the rest of the types, except aliases.
Aliases are problematic because opaques and associated types share the same type in the new solver. `@jackh726,` `@lcnr,` `@ShoyuVanilla` I'd like to hear ideas here. Anyway, even if we do nothing with them we already got a substantial improvement.
r? types
|
|
|
|
More details on about this fix:
https://rust-lang.zulipchat.com/#narrow/channel/187679-t-compiler.2Fparallel-rustc/topic/ICE.3A.20typecks.20AnonConst.20under.20parallel.20rustc.28.23141951.29/with/538200980
Co-authored-by: ywxt <ywxtcwh@gmail.com>
|
|
|
|
That way it doesn't need to be exported.
|
|
Because `rust_infer` is the only crate that uses it.
|
|
Exhaustive match isn't necessary for these trivial cases, and some
similar nearby methods are non-exhaustive.
|
|
Introduce PlaceContext::may_observe_address.
A small utility method to avoid open-coding the logic in several MIR opts.
|
|
|
|
|
|
Don't require next-solver `ProbeRef` to be `Copy`
rust-analyzer would like to use a non-interned `Probe` there.
Also rename it to `Probe` for this reason.
We can make it `Copy` (although then `Probe` will need to be `Clone` for rust-analyzer) but it seems just non-needed.
r? types
|
|
Allow `inline(always)` with a target feature behind a unstable feature `target_feature_inline_always`.
Rather than adding the inline always attribute to the function definition, we add it to the callsite. We can then check that the target features match and that the call would be safe to inline. If the function isn't inlined due to a mismatch, we emit a warning informing the user that the function can't be inlined due to the target feature mismatch.
See tracking issue rust-lang/rust#145574
|
|
fix drop scope for `super let` bindings within `if let`
Fixes rust-lang/rust#145328 by making non-lifetime-extended `super let` reuse the logic used to compute drop scopes for non-lifetime-extended temporaries.
Also fixes rust-lang/rust#145374, which regressed due to rust-lang/rust#143376 introducing `if let`-like scopes for match arms with guards.
Tracking issue for `super let`: rust-lang/rust#139076
This is a regression fix / breaking change for macros stably exposing `super let`, including `pin!` and `format_args!`.
Nominating to be discussed alongside rust-lang/rust#145328: ```@rustbot``` label +I-lang-nominated +I-libs-api-nominated
|
|
rust-analyzer would like to use a non-interned `Probe` there.
Also rename it to `Probe` for this reason.
|
|
Rollup of 14 pull requests
Successful merges:
- rust-lang/rust#144066 (stabilize c-style varargs for sysv64, win64, efiapi, aapcs)
- rust-lang/rust#145783 (add span to struct pattern rest (..))
- rust-lang/rust#146034 (Update target spec metadata of Arm64EC Windows and Trusty targets)
- rust-lang/rust#146064 (Add compiler error when trying to use concat metavar expr in repetitions)
- rust-lang/rust#146070 (rustdoc-search: skip loading unneeded fnData)
- rust-lang/rust#146088 (constify impl Try for ControlFlow)
- rust-lang/rust#146089 (fix a constness ordering bug in rustfmt)
- rust-lang/rust#146091 (fix rustdoc `render_call_locations` panicking because of default span `DUMMY_SP` pointing at non local-source file)
- rust-lang/rust#146094 (Make `Parser::parse_for_head` public for rustfmt usage)
- rust-lang/rust#146102 (Remove dead code stemming from an old effects desugaring)
- rust-lang/rust#146115 (Add maintainer for VxWorks)
- rust-lang/rust#146116 (Adjust issue-118306.rs test after LLVM change)
- rust-lang/rust#146117 (Fix search index generation)
- rust-lang/rust#146118 (improve process::abort rendering in Miri backtraces)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Remove dead code stemming from an old effects desugaring
CC https://github.com/rust-lang/rust/pull/132374, https://github.com/rust-lang/rust/pull/133443.
r? fee1-dead
|
|
cleanup and cache proof tree building
There's some cruft left over from when we had deep proof trees. We never encounter overflow when evaluating proof trees. Even if the recursion limit is `0`, we still only hit the overflow limit when evaluating nested goals of the root. The root goal simply inherits the `root_depth` of the `SearchGraph`.
Split `evaluate_root_goal_for_proof_tree` from the rest of the trait solver. This enables us to simplify the implementation of `evaluate_goal_raw` and the `ProofTreeBuilder` as we no longer need to manually track the state of the builder and can instead use separate types for that. It does require making a few internal methods into associated functions taking a `delegate` and a `span` instead of the `EvalCtxt` itself.
I've also split `SearchGraph::evaluate_goal` and `SearchGraph::evaluate_root_goal_for_proof_tree` for the same reason. Both functions don't actually share too much code, so by splitting them each version gets significantly easier to read.
Add a `query evaluate_root_goal_for_proof_tree_raw` to cache proof tree building. This requires arena allocating `inspect::Probe`. I've added a new type alias `I::ProbeRef` for this. We may need to adapt this for rust-analyzer? It would definitely be easy to remove the `Copy` bound here :thinking:
|
|
|
|
`-Znext-solver`: support non-defining uses in closures
Cleaned up version of rust-lang/rust#139587, finishing the implementation of https://github.com/rust-lang/types-team/issues/129. This does not affect stable. The reasoning for why this is the case is subtle however.
## What does it do
We split `do_mir_borrowck` into `borrowck_collect_region_constraints` and `borrowck_check_region_constraints`, where `borrowck_collect_region_constraints` returns an enormous `CollectRegionConstraintsResult` struct which contains all the relevant data to actually handle opaque type uses and to check the region constraints later on.
`query mir_borrowck` now simply calls `BorrowCheckRootCtxt::do_mir_borrowck` which starts by iterating over all nested bodies of the current function - visiting nested bodies before their parents - and computing their `CollectRegionConstraintsResult`.
After we've collected all constraints it's time to actually compute the concrete types for the opaques defined by this function. With this PR we now compute the concrete types of opaques for each body before using them to check the non-defining uses of any of them.
After we've computed the concrete types by using all bodies, we use `apply_computed_concrete_opaque_types` for each body to constrain non-defining uses, before finally finishing with `borrowck_check_region_constraints`. We always visit nested bodies before their parents when doing this.
## `ClosureRegionRequirements`
As we only call `borrowck_collect_region_constraints` for nested bodies before type checking the parent, we can't simply use the final `ClosureRegionRequirements` of the nested body during MIR type check. We instead track that we need to apply these requirements in `deferred_closure_requirements`.
We now manually apply the final closure requirements to each body after handling opaque types.
This works, except that we may need the region constraints of nested bodies to successfully define an opaque type in the parent. This is handled by using a new `fn compute_closure_requirements_modulo_opaques` which duplicates region checking - while ignoring any errors - before we've added the constraints from `apply_computed_concrete_opaque_types`. This is necessary for a lot of async tests, as pretty much the entire function is inside of an async block while the opaque type gets defined in the parent.
As an performance optimization we only use `fn compute_closure_requirements_modulo_opaques` in case the nested body actually depends on any opaque types. Otherwise we eagerly call `borrowck_check_region_constraints` and apply the final closure region requirements right away.
## Impact on stable code
Handling the opaque type uses in the parent function now only uses the closure requirements *modulo opaques*, while it previously also considered member constraints from nested bodies. `External` regions are never valid choice regions. Also, member constraints will never constrain a member region if it is required to be outlived by an external region, as that fails the upper-bound check. https://github.com/rust-lang/rust/blob/564ee219127b796d56f74767366fd359758b97de/compiler/rustc_borrowck/src/region_infer/opaque_types/member_constraints.rs#L90-L96
Member constraints therefore never add constraints for external regions :>
r? `@BoxyUwU`
|
|
|
|
Detect negative literal inferred to unsigned integer
```
error[E0277]: the trait bound `usize: Neg` is not satisfied
--> $DIR/negative-literal-infered-to-unsigned.rs:2:14
|
LL | for x in -5..5 {
| ^^ the trait `Neg` is not implemented for `usize`
|
help: consider specifying an integer type that can be negative
|
LL | for x in -5isize..5 {
| +++++
```
Applying this suggestion will always end up in another E0308 error at the point where the unsigned inference comes from, which should help with understanding what the actual problem is.
Fix rust-lang/rust#83413.
|
|
MIR dumping is a mess. There are lots of functions and entry points,
e.g. `dump_mir`, `dump_mir_with_options`, `dump_polonius_mir`,
`dump_mir_to_writer`. Also, it's crucial that `create_dump_file` is
never called without `dump_enabled` first being checked, but there is no
mechanism for ensuring this and it's hard to tell if it is satisfied on
all paths. (`dump_enabled` is checked twice on some paths, however!)
This commit introduces `MirWriter`, which controls the MIR writing, and
encapsulates the `extra_data` closure and `options`. Two existing
functions are now methods of this type. It sets reasonable defaults,
allowing the removal of many `|_, _| Ok(())` closures.
The commit also introduces `MirDumper`, which is layered on top of
`MirWriter`, and which manages the creation of the dump files,
encapsulating pass names, disambiguators, etc. Four existing functions
are now methods of this type.
- `MirDumper::new` will only succeed if dumps are enabled, and will
return `None` otherwise, which makes it impossible to dump when you
shouldn't.
- It also sets reasonable defaults for various things like
disambiguators, which means you no longer need to specify them in many
cases. When they do need to be specified, it's now done via setter
methods.
- It avoids some repetition. E.g. `dump_nll_mir` previously specifed the
pass name `"nll"` four times and the disambiguator `&0` three times;
now it specifies them just once, to put them in the `MirDumper`.
- For Polonius, the `extra_data` closure can now be specified earlier,
which avoids having to pass some arguments through some functions.
|
|
This commit exists purely to simplify reviewing: these functions will
become methods in the next commit. This commit indents them so that the
next commit is more readable.
|
|
The dynamic dispatch cost doesn't matter for MIR dumping, which is
perf-insensitive. And it's necessary for the next commit, which will
store some `extra_data` closures in a struct.
|
|
|
|
It has a single call site.
|
|
|
|
str: Stabilize `round_char_boundary` feature
Closes https://github.com/rust-lang/rust/issues/93743
FCP completed https://github.com/rust-lang/rust/issues/93743#issuecomment-3168382171
|
|
|
|
Switch next solver to use a specific associated type for trait def id
The compiler just puts `DefId` in there, but rust-analyzer uses different types for each kind of item.
See [the Zulip discussion](https://rust-lang.zulipchat.com/#narrow/channel/185405-t-compiler.2Frust-analyzer/topic/Implmentating.20New.20Trait.20Solver/near/534329794). In short, it will be a tremendous help to r-a to use specific associated types, while for the solver and the compiler it's a small change. So I ported `TraitId`, as a proof of concept and it's also likely the most impactful.
r? types
|
