about summary refs log tree commit diff
path: root/compiler/rustc_middle/src/ty
AgeCommit message (Collapse)AuthorLines
2025-05-02Use less rustc_type_ir in the compiler codebaseRomain Perier-1/+9
This commit does the following: - Replaces use of rustc_type_ir by rustc_middle in rustc_infer. - The DelayedMap type is exposed by rustc_middle so everything can be accessed through rustc_middle in a coherent manner. - API-layer traits, like InferCtxtLike, Interner or inherent::* must be accessed via rustc_type_ir, not rustc_middle::ty. For this reason these are not reexported by rustc_middle::ty. - Replaces use of ty::Interner by rustc_type_ir::Interner in rustc_trait_selection
2025-05-01Set groundwork for proper const normalizationBoxy-4/+15
2025-05-01Auto merge of #140145 - Zoxc:job-server-proxy, r=SparrowLiibors-0/+6
Add a jobserver proxy to ensure at least one token is always held This adds a jobserver proxy to ensure at least one token is always held by `rustc`. Currently with `-Z threads` `rustc` can temporarily give up all its tokens, causing `cargo` to spawn additional `rustc` instances beyond the job limit. The current behavior causes an issue with `cargo fix` which has a global lock preventing concurrent `rustc` instances, but it also holds a jobserver token, causing a deadlock when `rustc` gives up its token. That is fixed by this PR. Fixes https://github.com/rust-lang/rust/issues/67385. Fixes https://github.com/rust-lang/rust/issues/133873. Fixes https://github.com/rust-lang/rust/issues/140093.
2025-04-30Rollup merge of #140516 - rperier:type-ir-to-type-middle, r=lcnrMatthias Krüger-0/+1
Replace use of rustc_type_ir by rustc_middle cc #138449 I want to help on this issue. I have replaced all the rustc_type_ir uses by the equivalent type in rustc_middle. DelayedSet is also re-exposed by rustc_middle.
2025-04-30Use less rustc_type_ir in the compiler codebaseRomain Perier-0/+1
This commit does the following: - Replaces use of rustc_type_ir by rustc_middle - Removes the rustc_type_ir dependency - The DelayedSet type is exposed by rustc_middle so everything can be accessed through rustc_middle in a coherent manner.
2025-04-29canonical no type foldable :<lcnr-2/+2
2025-04-29Rollup merge of #139909 - oli-obk:or-patterns, r=BoxyUwUTrevor Gross-1/+61
implement or-patterns for pattern types These are necessary to represent `NonZeroI32`, as the range for that is `..0 | 1..`. The `rustc_scalar_layout_range_*` attributes avoided this by just implementing wraparound and having a single `1..=-1` range effectively. See https://rust-lang.zulipchat.com/#narrow/channel/481660-t-lang.2Fpattern-types/topic/.60or.20pattern.60.20representation.20in.20type.20system/with/504217694 for some background discussion cc https://github.com/rust-lang/rust/issues/123646 r? `@BoxyUwU`
2025-04-29Remove global `next_disambiguator` state and handle it with a ↵John Kåre Alsaker-9/+15
`DisambiguatorState` type
2025-04-29Add some commentsJohn Kåre Alsaker-0/+1
2025-04-29Add a jobserver proxy to ensure at least one token is always heldJohn Kåre Alsaker-0/+5
2025-04-28Rollup merge of #140022 - dianne:box-deref-pats, r=NadrierilChris Denton-0/+15
allow deref patterns to move out of boxes This adds a case to lower deref patterns on boxes using a built-in deref instead of a `Deref::deref` or `DerefMut::deref_mut` call: if `deref!(inner): Box<T>` is matching on place `place`, the inner pattern `inner` now matches on `*place` rather than a temporary. No longer needing to call a method also means it won't borrow the scrutinee in match arms. This allows for bindings in `inner` to move out of `*place`. For comparison with box patterns, this uses the same MIR lowering but different THIR. Consequently, deref patterns on boxes are treated the same as any other deref patterns in match exhaustiveness analysis. Box patterns can't quite be implemented in terms of deref patterns until exhaustiveness checking for deref patterns is implemented (I'll open a PR for exhaustiveness soon!). Tracking issue: #87121 r? ``@Nadrieril``
2025-04-28Auto merge of #140388 - GuillaumeGomez:rollup-aj9o3ch, r=GuillaumeGomezbors-31/+31
Rollup of 7 pull requests Successful merges: - #140056 (Fix a wrong error message in 2024 edition) - #140220 (Fix detection of main function if there are expressions around it) - #140249 (Remove `weak` alias terminology) - #140316 (Introduce `BoxMarker` to improve pretty-printing correctness) - #140347 (ci: clean more disk space in codebuild) - #140349 (ci: use aws codebuild for the `dist-x86_64-linux` job) - #140379 (rustc-dev-guide subtree update) r? `@ghost` `@rustbot` modify labels: rollup
2025-04-28Rollup merge of #140249 - BoxyUwU:remove_weak_alias_terminology, r=oli-obkGuillaume Gomez-31/+31
Remove `weak` alias terminology I find the "weak" alias terminology to be quite confusing. It implies the existence of "strong" aliases (which do not exist) and I'm not really sure what about weak aliases is "weak". I much prefer "free alias" as the term. I think it's much more obvious what it means as "free function" is a well defined term that already exists in rust. It's also a little confusing given "weak alias" is already a term in linker/codegen spaces which are part of the compiler too. Though I'm not particularly worried about that as it's usually very obvious if you're talking about the type system or not lol. I'm also currently trying to write documentation about aliases and it's somewhat awkward/confusing to be talking about *weak* aliases, when I'm not really sure what the basis for that as the term actually *is*. I would also be happy to just find out there's a nice meaning behind calling them "weak" aliases :-) r? `@oli-obk` maybe we want a types MCP to decide on a specific naming here? or maybe we think its just too late to go back on this naming decision ^^'
2025-04-28AsyncDrop implementation using shim codegen of ↵Andrew Zhogin-225/+214
async_drop_in_place::{closure}, scoped async drop added.
2025-04-28Add or-patterns to pattern typesOli Scherer-0/+59
2025-04-28Split out various pattern type matches into their own functionOli Scherer-1/+2
2025-04-26Rollup merge of #140320 - lcnr:wf-use-term, r=compiler-errorsMatthias Krüger-5/+29
replace `GenericArg` with `Term` where applicable r? types
2025-04-26convert some `GenericArg` to `Term`lcnr-5/+29
2025-04-25handle specialization in the new trait solverlcnr-0/+4
uwu :3
2025-04-24lower deref patterns on boxes using built-in derefsdianne-0/+15
This allows deref patterns to move out of boxes. Implementation-wise, I've opted to put the information of whether a deref pattern uses a built-in deref or a method call in the THIR. It'd be a bit less code to check `.is_box()` everywhere, but I think this way feels more robust (and we don't have a `mutability` field in the THIR that we ignore when the smart pointer's a box). I'm not sure about the naming (or using `ByRef`), though.
2025-04-24norm nested aliases before evaluating the parent goallcnr-4/+4
2025-04-24Remove `weak` alias terminologyBoxy-31/+31
2025-04-23Auto merge of #138845 - compiler-errors:stall-generators, r=lcnrbors-4/+19
Properly stall coroutine witnesses in new solver TODO: write description r? lcnr
2025-04-23MoreMichael Goulet-5/+12
2025-04-22Don't compute query unless in new solverMichael Goulet-1/+5
2025-04-22Properly drain pending obligations for coroutinesMichael Goulet-2/+6
2025-04-22Use `is_lang_item` and `as_lang_item` instead of handrolling their logicOli Scherer-3/+1
2025-04-21Rollup merge of #140052 - GuillaumeGomez:fix-140026, r=nnethercoteChris Denton-0/+2
Fix error when an intra doc link is trying to resolve an empty associated item Fixes https://github.com/rust-lang/rust/issues/140026. Assigning ```@nnethercote``` since they're the one who wrote the initial change. I updated rustdoc code instead of compiler's because I think it makes more sense that the caller ensures on their side that the name they're looking for isn't empty. r? ```@nnethercote```
2025-04-19Update docs for `AssocItems::filter_by_name_unhygienic`Guillaume Gomez-0/+2
2025-04-18Re-remove `AdtFlags::IS_ANONYMOUS`Sky-2/+0
2025-04-18Rollup merge of #138528 - dianne:implicit-deref-patterns, r=NadrierilMatthias Krüger-6/+47
deref patterns: implement implicit deref patterns This implements implicit deref patterns (per https://hackmd.io/4qDDMcvyQ-GDB089IPcHGg#Implicit-deref-patterns) and adds tests and an unstable book chapter. Best reviewed commit-by-commit. Overall there's a lot of additions, but a lot of that is tests, documentation, and simple(?) refactoring. Tracking issue: #87121 r? ``@Nadrieril``
2025-04-17Rollup merge of #139770 - nnethercote:rename-LifetimeName, r=BoxyUwUMatthias Krüger-2/+2
Rename `LifetimeName` as `LifetimeKind`. It's a much better name, more consistent with how we name such things. Also rename `Lifetime::res` as `Lifetime::kind` to match. I suspect this field used to have the type `LifetimeRes` and then the type was changed but the field name remained the same. r? ``@BoxyUwU``
2025-04-16lower implicit deref patterns to THIRdianne-3/+12
Since this uses `pat_adjustments`, I've also tweaked the documentation to mention implicit deref patterns and made sure the pattern migration diagnostic logic accounts for it. I'll adjust `ExprUseVisitor` in a later commit and add some tests there for closure capture inference.
2025-04-16Auto merge of #139768 - compiler-errors:split-fold, r=lcnrbors-67/+210
Split `TypeFolder` and `FallibleTypeFolder` atwain Right now there is a coherence problem with `TypeFolder` and `FallibleTypeFolder`. Namely, it's impossible to implement a `FallibleTypeFolder` that is generic over interner, b/c it has a *downstream* conflict with the blanket impl: ``` impl<I, F> FallibleTypeFolder<I> for F where F: TypeFolder<I> {} ``` Because downstream crates may implement `TypeFolder<SomeLocalInterner>` for the fallible type folder. This PR removes the relationship between `FallibleTypeFolder` and `TypeFolder`; it leads to *modest* code duplication, but otherwise does not affect perf and really doesn't matter in general.
2025-04-16Rename `LifetimeName` as `LifetimeKind`.Nicholas Nethercote-2/+2
It's a much better name, more consistent with how we name such things. Also rename `Lifetime::res` as `Lifetime::kind` to match. I suspect this field used to have the type `LifetimeRes` and then the type was changed but the field name remained the same.
2025-04-15Split TypeFolder and FallibleTypeFolderMichael Goulet-67/+210
2025-04-15Auto merge of #139845 - Zalathar:rollup-u5u5y1v, r=Zalatharbors-86/+117
Rollup of 17 pull requests Successful merges: - #138374 (Enable contracts for const functions) - #138380 (ci: add runners for vanilla LLVM 20) - #138393 (Allow const patterns of matches to contain pattern types) - #139517 (std: sys: process: uefi: Use NULL stdin by default) - #139554 (std: add Output::exit_ok) - #139660 (compiletest: Add an experimental new executor to replace libtest) - #139669 (Overhaul `AssocItem`) - #139671 (Proc macro span API redesign: Replace proc_macro::SourceFile by Span::{file, local_file}) - #139750 (std/thread: Use default stack size from menuconfig for NuttX) - #139772 (Remove `hir::Map`) - #139785 (Let CStrings be either 1 or 2 byte aligned.) - #139789 (do not unnecessarily leak auto traits in item bounds) - #139791 (drop global where-bounds before merging candidates) - #139798 (normalize: prefer `ParamEnv` over `AliasBound` candidates) - #139822 (Fix: Map EOPNOTSUPP to ErrorKind::Unsupported on Unix) - #139833 (Fix some HIR pretty-printing problems) - #139836 (Basic tests of MPMC receiver cloning) r? `@ghost` `@rustbot` modify labels: rollup
2025-04-15Rollup merge of #139772 - nnethercote:rm-hir-Map, r=ZalatharStuart Cook-15/+3
Remove `hir::Map` A follow-up to https://github.com/rust-lang/rust/pull/139232. r? `@Zalathar`
2025-04-15Rollup merge of #139669 - nnethercote:overhaul-AssocItem, r=oli-obkStuart Cook-71/+114
Overhaul `AssocItem` `AssocItem` has multiple fields that only make sense some of the time. E.g. the `name` can be empty if it's an RPITIT associated type. It's clearer and less error prone if these fields are moved to the relevant `kind` variants. r? ``@fee1-dead``
2025-04-15Auto merge of #139826 - matthiaskrgr:rollup-0q0qvkd, r=matthiaskrgrbors-10/+4
Rollup of 8 pull requests Successful merges: - #139745 (Avoid unused clones in `Cloned<I>` and `Copied<I>`) - #139757 (opt-dist: use executable-extension for host llvm-profdata) - #139778 (Add test for issue 34834) - #139783 (Use `compiletest-ignore-dir` for bootstrap self-tests) - #139797 (Allow (but don't require) `#[unsafe(naked)]` so that `compiler-builtins` can upgrade to it) - #139799 (Specify `--print info=file` syntax in `--help`) - #139811 (Use `newtype_index!`-generated types more idiomatically) - #139813 (Miri subtree update) r? `@ghost` `@rustbot` modify labels: rollup
2025-04-15Move `name` field from `AssocItem` to `AssocKind` variants.Nicholas Nethercote-40/+72
To accurately reflect that RPITIT assoc items don't have a name. This avoids the use of `kw::Empty` to mean "no name", which is error prone. Helps with #137978.
2025-04-15Move two methods from `AssocKind` to `AssocItem`.Nicholas Nethercote-18/+15
Because all the other similar methods are on `AssocItem`.
2025-04-15Move `opt_rpitit_info` field to `hir::AssocKind::Type`.Nicholas Nethercote-18/+26
From `hir::AssocItem`.
2025-04-14Auto merge of #139577 - davidtwco:sizedness-go-vroom, r=oli-obkbors-7/+7
re-use `Sized` fast-path There's an existing fast path for the `type_op_prove_predicate` predicate, checking for trivially `Sized` types, which can be re-used when evaluating obligations within queries. This should improve performance and was found to be beneficial in #137944. r? types
2025-04-14Use `newtype_index!`-generated types more idiomaticallyYotam Ofek-10/+4
2025-04-14Auto merge of #139241 - bvanjoi:less-decoding, r=petrochenkovbors-1/+1
don't store opaque info during encoding Now `remapped_ctxts` reserved and let's check the performance. r? `@petrochenkov`
2025-04-14Move `has_self` field to `hir::AssocKind::Fn`.Nicholas Nethercote-34/+40
`hir::AssocItem` currently has a boolean `fn_has_self_parameter` field, which is misplaced, because it's only relevant for associated fns, not for associated consts or types. This commit moves it (and renames it) to the `AssocKind::Fn` variant, where it belongs. This requires introducing a new C-style enum, `AssocTag`, which is like `AssocKind` but without the fields. This is because `AssocKind` values are passed to various functions like `find_by_ident_and_kind` to indicate what kind of associated item should be searched for, and having to specify `has_self` isn't relevant there. New methods: - Predicates `AssocItem::is_fn` and `AssocItem::is_method`. - `AssocItem::as_tag` which converts `AssocItem::kind` to `AssocTag`. Removed `find_by_name_and_kinds`, which is unused. `AssocItem::descr` can now distinguish between methods and associated functions, which slightly improves some error messages.
2025-04-13Rollup merge of #139722 - jackh726:patternkind-walk-toir, r=compiler-errorsJacob Pratt-595/+93
Move some things to rustc_type_ir This moves - `PatternKind` - `FlagComputation` - `TypeWalker` into rustc_type_ir. Not strictly required for rust-analyzer next-solve integration, but helps with code duplication. r? types
2025-04-14Remove unused `Map` field from `TraitObjectVisitor`.Nicholas Nethercote-3/+3
Also reduce visibility.
2025-04-14Remove unused `StaticLifetimeVisitor`.Nicholas Nethercote-12/+0