about summary refs log tree commit diff
path: root/compiler/rustc_hir_analysis/src
AgeCommit message (Collapse)AuthorLines
2024-11-23Add simd_relaxed_fma intrinsicCaleb Zulawski-1/+3
2024-11-23Dont create object type when more than one principal is presentMichael Goulet-4/+9
2024-11-23no more Reveal :(lcnr-9/+9
2024-11-23Auto merge of #132915 - veluca93:unsafe-fields, r=jswrennbors-32/+96
Implement the unsafe-fields RFC. RFC: rust-lang/rfcs#3458 Tracking: - https://github.com/rust-lang/rust/issues/132922 r? jswrenn
2024-11-22Simplify fulfill_implicationMichael Goulet-7/+2
2024-11-21Implement the unsafe-fields RFC.Luca Versari-32/+96
Co-Authored-By: Jacob Pratt <jacob@jhpratt.dev>
2024-11-21Rollup merge of #133218 - compiler-errors:const-opaque, r=fee1-deadMatthias Krüger-5/+22
Implement `~const` item bounds in RPIT an RPIT in a `const fn` is allowed to be conditionally const itself :) r? fee1-dead or reroll
2024-11-21Rollup merge of #132207 - compiler-errors:tweak-res-mod-segment, r=petrochenkovMatthias Krüger-2/+2
Store resolution for self and crate root module segments Let's make sure to record the segment resolution for `self::`, `crate::` and `$crate::`. I'm actually somewhat surprised that the only diagnostic that uses this is the one that errors on invalid generics on a module segment... but seems strictly more correct regardless, and there may be other diagnostics using these segments resolutions that just haven't been tested for `self`. Also includes a drive-by on `report_prohibit_generics_error`.
2024-11-20Auto merge of #133261 - matthiaskrgr:rollup-ekui4we, r=matthiaskrgrbors-14/+71
Rollup of 6 pull requests Successful merges: - #129838 (uefi: process: Add args support) - #130800 (Mark `get_mut` and `set_position` in `std::io::Cursor` as const.) - #132708 (Point at `const` definition when used instead of a binding in a `let` statement) - #133226 (Make `PointerLike` opt-in instead of built-in) - #133244 (Account for `wasm32v1-none` when exporting TLS symbols) - #133257 (Add `UnordMap::clear` method) r? `@ghost` `@rustbot` modify labels: rollup
2024-11-20we should not be reporting generic error if there is not a segment to denyMichael Goulet-2/+2
2024-11-20Make PointerLike opt-in as a traitMichael Goulet-14/+71
2024-11-20reduce false positives of tail-expr-drop-order from consumed valuesDing Xiang Fei-2/+18
take 2 open up coroutines tweak the wordings the lint works up until 2021 We were missing one case, for ADTs, which was causing `Result` to yield incorrect results. only include field spans with significant types deduplicate and eliminate field spans switch to emit spans to impl Drops Co-authored-by: Niko Matsakis <nikomat@amazon.com> collect drops instead of taking liveness diff apply some suggestions and add explantory notes small fix on the cache let the query recurse through coroutine new suggestion format with extracted variable name fine-tune the drop span and messages bugfix on runtime borrows tweak message wording filter out ecosystem types earlier apply suggestions clippy check lint level at session level further restrict applicability of the lint translate bid into nop for stable mir detect cycle in type structure
2024-11-20Auto merge of #133212 - lcnr:questionable-uwu, r=compiler-errorsbors-17/+22
continue `ParamEnv` to `TypingEnv` transition cc #132279 r? `@compiler-errors`
2024-11-19additional `TypingEnv` cleanupslcnr-3/+3
2024-11-19`InterpCx` store `TypingEnv` instead of a `ParamEnv`lcnr-2/+2
2024-11-19Implement ~const opaquesMichael Goulet-1/+18
2024-11-19Rename implied_const_bounds to explicit_implied_const_boundsMichael Goulet-4/+4
2024-11-19move `fn is_item_raw` to `TypingEnv`lcnr-12/+17
2024-11-19Fix broken intra-doc linkBoxy-1/+1
2024-11-19Introduce `min_generic_const_args` and directly represent pathsNoah Lev-37/+200
Co-authored-by: Boxy UwU <rust@boxyuwu.dev> Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
2024-11-18reviewlcnr-1/+1
2024-11-18use `TypingEnv` when no `infcx` is availablelcnr-17/+24
the behavior of the type system not only depends on the current assumptions, but also the currentnphase of the compiler. This is mostly necessary as we need to decide whether and how to reveal opaque types. We track this via the `TypingMode`.
2024-11-17Rollup merge of #132795 - compiler-errors:refine-rpitit, r=lcnrJacob Pratt-1/+111
Check `use<..>` in RPITIT for refinement `#![feature(precise_capturing_in_traits)]` allows users to write `+ use<>` bounds on RPITITs to control what lifetimes are captured by the RPITIT. Since RPITITs currently also warn for refinement in implementations, this PR extends that refinement check for cases where we *undercapture* in an implementation, since that may be indirectly "promising" a more relaxed outlives bound than the impl author intended. For an opaque to be refining, we need to capture *fewer* parameters than those mentioned in the captured params of the trait. For example: ``` trait TypeParam<T> { fn test() -> impl Sized; } // Indirectly capturing a lifetime param through a type param substitution. impl<'a> TypeParam<&'a ()> for i32 { fn test() -> impl Sized + use<> {} //~^ WARN impl trait in impl method captures fewer lifetimes than in trait } ``` Since the opaque in the method (implicitly) captures `use<Self, T>`, and `Self = i32, T = &'a ()` in the impl, we must mention `'a` in our `use<..>` on the impl. Tracking: * https://github.com/rust-lang/rust/issues/130044
2024-11-18Check use<..> in RPITIT for refinementMichael Goulet-1/+111
2024-11-17Auto merge of #120370 - x17jiri:likely_unlikely_fix, r=saethlinbors-4/+2
Likely unlikely fix RFC 1131 ( https://github.com/rust-lang/rust/issues/26179 ) added likely/unlikely intrinsics, but they have been broken for a while: https://github.com/rust-lang/rust/issues/96276 , https://github.com/rust-lang/rust/issues/96275 , https://github.com/rust-lang/rust/issues/88767 . This PR tries to fix them. Changes: - added a new `cold_path()` intrinsic - `likely()` and `unlikely()` changed to regular functions implemented using `cold_path()`
2024-11-17Likely unlikely fixJiri Bobek-4/+2
2024-11-16Rollup merge of #132832 - compiler-errors:late-ty, r=cjgillotMatthias Krüger-22/+29
Deny capturing late-bound ty/const params in nested opaques First, this reverts a7f609504c92c9912b61025ae26a5404d3ee4311. I can't exactly remember why I approved this specific bit of https://github.com/rust-lang/rust/pull/132466; specifically, I don't know that the purpose of that commit is, and afaict we will never have an opaque that captures late-bound params through a const because opaques can't be used inside of anon consts. Am I missing something `@cjgillot?` Since I can't see a case where this matters, and no tests seem to fail. The second commit adds a `deny_late_regions: bool` to distinguish `Scope::LateBoundary` which should deny *any* late-bound params or just ty/consts. Then, when resolving opaques we wrap ourselves in a `Scope::LateBoundary { deny_late_regions: false }` so that we deny late-bound ty/const, which fixes a bunch of ICEs that all vaguely look like `impl for<T> Trait<Assoc = impl OtherTrait<T>>`. I guess this could be achieved other ways; for example, with a different scope kind, or maybe we could just reuse `Scope::Opaque`. But this seems a bit more verbose. I'm open to feedback anyways. Fixes #131535 Fixes #131637 Fixes #132530 I opted to remove those crashes tests ^ without adding them as regular tests, since they're basically triggering uninteresting late-bound ICEs far off in the trait solver, and the reason that existing tests such as `tests/ui/type-alias-impl-trait/non-lifetime-binder-in-constraint.rs` don't ICE are kinda just coincidental (i.e. due to a missing impl block). I don't really feel motivated to add random permutations to tests just to exercise non-lifetime binders. r? cjgillot
2024-11-11Simplify some places that deal with generic parameter defaultsLeón Orell Valerian Liehr-75/+23
2024-11-10Deny capturing late-bound ty/ct params in nested opaquesMichael Goulet-10/+27
2024-11-10Revert "Skip late-bound lifetimes when crossing an AnonConst."Michael Goulet-12/+2
This reverts commit a7f609504c92c9912b61025ae26a5404d3ee4311.
2024-11-08Rollup merge of #132757 - compiler-errors:yeet-check-wf, r=lcnrJubilee-19/+136
Get rid of `check_opaque_type_well_formed` Instead, replicate it by improving the span of the opaque in `check_opaque_meets_bounds`. This has two consequences: 1. We now prefer "concrete type differs" errors, since we'll hit those first before we check the opaque is WF. 2. Spans have gotten slightly worse. Specifically, (2.) could be improved by adding a new obligation cause that explains that the definition's environment has stronger assumptions than the declaration. r? lcnr
2024-11-08remove support for rustc_safe_intrinsic attribute; use rustc_intrinsic ↵Ralf Jung-5/+3
functions instead
2024-11-08Manually register some bounds for a better spanMichael Goulet-8/+37
2024-11-08Get rid of check_opaque_type_well_formedMichael Goulet-17/+105
2024-11-07Rollup merge of #132734 - RalfJung:platform-intrinsic, r=compiler-errorsMatthias Krüger-2/+1
remove 'platform-intrinsic' ABI leftovers This was removed a while ago, but some parts haven't been fully cleaned up.
2024-11-07 remove 'platform-intrinsic' ABI leftoversRalf Jung-2/+1
2024-11-05Remove unused errs.rs fileEric Huss-88/+0
This module was removed in #124895, but the actual file was not removed.
2024-11-05Auto merge of #132580 - compiler-errors:globs, r=Noratriebbors-31/+38
Remove unnecessary pub enum glob-imports from `rustc_middle::ty` We used to have an idiom in the compiler where we'd prefix or suffix all the variants of an enum, for example `BoundRegionKind`, with something like `Br`, and then *glob-import* that enum variant directly. `@noratrieb` brought this up, and I think that it's easier to read when we just use the normal style `EnumName::Variant`. This PR is a bit large, but it's just naming. The only somewhat opinionated change that this PR does is rename `BorrowKind::Imm` to `BorrowKind::Immutable` and same for the other variants. I think these enums are used sparingly enough that the extra length is fine. r? `@noratrieb` or reassign
2024-11-04Rollup merge of #132559 - bvanjoi:fix-132534, r=compiler-errorsMatthias Krüger-8/+2
find the generic container rather than simply looking up for the assoc with const arg Fixes #132534 This issue is caused by mismatched generic parameters. Previously, it tried to find `T` in `trait X`, but after this change, it will find `T` in `fn a`. r? `@compiler-errors` as this assertion was introduced by you.
2024-11-04ty::BrK -> ty::BoundRegionKind::KMichael Goulet-22/+29
2024-11-04ty::KContainer -> ty::AssocItemContainer::KMichael Goulet-9/+9
2024-11-04find the generic container rather than simply looking up for the assoc with ↵bohan-8/+2
const arg
2024-11-03Rollup merge of #132574 - workingjubilee:abi-in-compiler, r=compiler-errorsJubilee-34/+37
compiler: Directly use rustc_abi almost everywhere Use rustc_abi instead of rustc_target where applicable. This is mostly described by the following substitutions: ```rust match path_substring { rustc_target::spec::abi::Abi => rustc_abi::ExternAbi, rustc_target::abi::call => rustc_target::callconv, rustc_target::abi => rustc_abi, } ``` A number of spot-fixes make that not quite the whole story. The main exception is in 33edc68 where I get a lot more persnickety about how things are imported, especially in `rustc_middle::ty::layout`, not just from where. This includes putting an end to a reexport of `rustc_middle::ty::ReprOptions`, for the same reason that the rest of this change is happening: reexports mostly confound things. This notably omits rustc_passes and the ast crates, as I'm still examining a question I have about how they do stability checking of `extern "Abi"` strings and if I can simplify their logic. The rustc_abi and rustc_target crates also go untouched because they will be entangled in that cleanup. r? compiler-errors
2024-11-03compiler: Directly use rustc_abi in hir_{analysis,typeck}Jubilee Young-34/+37
2024-11-03Rename the FIXMEs, remove a few that dont matter anymoreMichael Goulet-3/+1
2024-11-02Rollup merge of #132466 - cjgillot:opaque-late, r=compiler-errorsMatthias Krüger-3/+20
Account for late-bound depth when capturing all opaque lifetimes. Fixes https://github.com/rust-lang/rust/issues/132429 r? ````@compiler-errors````
2024-11-01Skip late-bound lifetimes when crossing an AnonConst.Camille GILLOT-2/+12
2024-11-01Account for late-bound depth when capturing all opaque lifetimes.Camille GILLOT-1/+8
2024-11-01Auto merge of #132196 - compiler-errors:probe_ty_param_bounds, r=petrochenkovbors-49/+94
Some where clause lowering simplifications Rename `PredicateFilter::SelfThatDefines` to `PredicateFilter::SelfTraitThatDefines` to make it clear that it's only concerned with converting *traits*, and make it do a bit less work when converting bounds. Also, make the predicate filter matching in `probe_ty_param_bounds_in_generics` explicit, and simply the args it receives a bit.
2024-10-31Rollup merge of #132209 - compiler-errors:modifiers, r=fmeaseJubilee-20/+35
Fix validation when lowering `?` trait bounds Pass the unlowered (`rustc_hir`) polarity to `lower_poly_trait_ref`. This allows us to actually *validate* that generic args are actually valid on `?Trait` paths. This actually regressed in #113671 because that PR changed the behavior where we were inadvertently re-lowering paths as `BoundPolarity::Positive`, which was also coincidentally the only place we were enforcing the generics on `?Trait` paths were correct.