about summary refs log tree commit diff
path: root/compiler/rustc_hir_analysis/src/check
AgeCommit message (Collapse)AuthorLines
2024-10-28Rollup merge of #132255 - workingjubilee:layout-is-🏚️, r=compiler-errorsJubilee-1/+1
Add `LayoutS::is_uninhabited` and use it Use accessors for the things that accessors are good at: reducing everyone's need to be nosy and peek at the internals of every data structure.
2024-10-28Rollup merge of #132249 - workingjubilee:add-rustc-abi, r=compiler-errorsJubilee-3/+3
compiler: Add rustc_abi dependence to the compiler Depend on rustc_abi in compiler crates that use it indirectly but have not yet taken on that dependency, and are not *significantly* entangled in my other PRs. This leaves an "excise rustc_target" step after the dust settles.
2024-10-28compiler: Add `is_uninhabited` and use LayoutS accessorsJubilee Young-1/+1
This reduces the need of the compiler to peek on the fields of LayoutS.
2024-10-27compiler: Add rustc_abi dependence to the compilerJubilee Young-3/+3
Depend on rustc_abi in compiler crates that use it indirectly but have not yet taken on that dependency, and are not entangled in my other PRs. This leaves an "excise rustc_target" step after the dust settles.
2024-10-27Remove ObligationCause::span() methodMichael Goulet-3/+3
2024-10-24Auto merge of #132116 - matthiaskrgr:rollup-3a0ia4r, r=matthiaskrgrbors-3/+1
Rollup of 4 pull requests Successful merges: - #131790 (Document textual format of SocketAddrV{4,6}) - #131983 (Stabilize shorter-tail-lifetimes) - #132097 (sanitizer.md: LeakSanitizer is not supported on aarch64 macOS) - #132107 (Remove visit_expr_post from ast Visitor) r? `@ghost` `@rustbot` modify labels: rollup
2024-10-24Rollup merge of #131983 - dingxiangfei2009:stabilize-shorter-tail-lifetimes, ↵Matthias Krüger-3/+1
r=lcnr Stabilize shorter-tail-lifetimes Close #131445 Tracked by #123739 We found a test case `tests/ui/drop/drop_order.rs` that had not been covered by the change. The test fixture is fixed now with the correct expectation.
2024-10-24Be better at enforcing that const_conditions is only called on const itemsMichael Goulet-11/+12
2024-10-24Implement const effect predicate in new solverMichael Goulet-9/+138
2024-10-24Remove associated type based effects logicMichael Goulet-13/+2
2024-10-24Rollup merge of #131756 - compiler-errors:deeply-normalize-type-err, r=lcnrStuart Cook-8/+11
Deeply normalize `TypeTrace` when reporting type error in new solver Normalize the values that come from the `TypeTrace` for various type mismatches. Side-note: We can't normalize the `TypeError` itself bc it may come from instantiated binders, so it may reference values from within the probe... r? lcnr
2024-10-24Rollup merge of #130225 - adetaylor:rename-old-receiver, r=wesleywiserStuart Cook-1/+1
Rename Receiver -> LegacyReceiver As part of the "arbitrary self types v2" project, we are going to replace the current `Receiver` trait with a new mechanism based on a new, different `Receiver` trait. This PR renames the old trait to get it out the way. Naming is hard. Options considered included: * HardCodedReceiver (because it should only be used for things in the standard library, and hence is sort-of hard coded) * LegacyReceiver * TargetLessReceiver * OldReceiver These are all bad names, but fortunately this will be temporary. Assuming the new mechanism proceeds to stabilization as intended, the legacy trait will be removed altogether. Although we expect this trait to be used only in the standard library, we suspect it may be in use elsehwere, so we're landing this change separately to identify any surprising breakages. It's known that this trait is used within the Rust for Linux project; a patch is in progress to remove their dependency. This is a part of the arbitrary self types v2 project, https://github.com/rust-lang/rfcs/pull/3519 https://github.com/rust-lang/rust/issues/44874 r? `@wesleywiser`
2024-10-24Plumb through param_env to note_type_errMichael Goulet-8/+11
2024-10-24stabilize if_let_rescopeDing Xiang Fei-4/+2
2024-10-23Rollup merge of #131979 - compiler-errors:compare-pred-entail, r=fmeaseLeón Orell Valerian Liehr-91/+66
Minor tweaks to `compare_impl_item.rs` 1. Stop using the `InstantiatedPredicates` struct for `hybrid_preds` in `compare_impl_item.rs`, since we never actually push anything into the `spans` part of it. 2. Remove redundant impl args and don't do useless identity substitution, prefer calling `instantiate_identity`.
2024-10-24stabilize shorter-tail-lifetimesDing Xiang Fei-3/+1
2024-10-23More compare_impl_item simplificationsMichael Goulet-73/+52
2024-10-23nightly feature tracking: get rid of the per-feature bool fieldsRalf Jung-10/+12
2024-10-22Rename Receiver -> LegacyReceiverAdrian Taylor-1/+1
As part of the "arbitrary self types v2" project, we are going to replace the current `Receiver` trait with a new mechanism based on a new, different `Receiver` trait. This PR renames the old trait to get it out the way. Naming is hard. Options considered included: * HardCodedReceiver (because it should only be used for things in the standard library, and hence is sort-of hard coded) * LegacyReceiver * TargetLessReceiver * OldReceiver These are all bad names, but fortunately this will be temporary. Assuming the new mechanism proceeds to stabilization as intended, the legacy trait will be removed altogether. Although we expect this trait to be used only in the standard library, we suspect it may be in use elsehwere, so we're landing this change separately to identify any surprising breakages. It's known that this trait is used within the Rust for Linux project; a patch is in progress to remove their dependency. This is a part of the arbitrary self types v2 project, https://github.com/rust-lang/rfcs/pull/3519 https://github.com/rust-lang/rust/issues/44874 r? @wesleywiser
2024-10-22Auto merge of #129935 - RalfJung:unsupported_calling_conventions, ↵bors-28/+17
r=compiler-errors make unsupported_calling_conventions a hard error This has been a future-compat lint (not shown in dependencies) since Rust 1.55, released 3 years ago. Hopefully that was enough time so this can be made a hard error now. Given that long timeframe, I think it's justified to skip the "show in dependencies" stage. There were [not many crates hitting this](https://github.com/rust-lang/rust/pull/86231#issuecomment-866300943) even when the lint was originally added. This should get cratered, and I assume then it needs a t-compiler FCP. (t-compiler because this looks entirely like an implementation oversight -- for the vast majority of ABIs, we already have a hard error, but some were initially missed, and we are finally fixing that.) Fixes https://github.com/rust-lang/rust/pull/87678
2024-10-20tweak hybrid predsMichael Goulet-18/+14
2024-10-20make unsupported_calling_conventions a hard errorRalf Jung-28/+17
2024-10-19Get rid of const eval_* and try_eval_* helpersMichael Goulet-4/+6
2024-10-16Rollup merge of #131753 - compiler-errors:swap-secondary, r=jieyouxuMatthias Krüger-7/+3
Unify `secondary_span` and `swap_secondary_and_primary` args in `note_type_err` Tiny tweak b/c working w `note_type_err` is kinda a mess.
2024-10-15Don't report bivariance error when nesting a struct with field errors into ↵Michael Goulet-10/+50
another struct
2024-10-15Unify secondary_span and swap_secondary_and_primaryMichael Goulet-7/+3
2024-10-15Auto merge of #131723 - matthiaskrgr:rollup-krcslig, r=matthiaskrgrbors-4/+4
Rollup of 9 pull requests Successful merges: - #122670 (Fix bug where `option_env!` would return `None` when env var is present but not valid Unicode) - #131095 (Use environment variables instead of command line arguments for merged doctests) - #131339 (Expand set_ptr_value / with_metadata_of docs) - #131652 (Move polarity into `PolyTraitRef` rather than storing it on the side) - #131675 (Update lint message for ABI not supported) - #131681 (Fix up-to-date checking for run-make tests) - #131702 (Suppress import errors for traits that couldve applied for method lookup error) - #131703 (Resolved python deprecation warning in publish_toolstate.py) - #131710 (Remove `'apostrophes'` from `rustc_parse_format`) r? `@ghost` `@rustbot` modify labels: rollup
2024-10-15Rollup merge of #131328 - ↵Matthias Krüger-4/+1
ismailarilik:remove-unnecessary-sorts-in-rustc-hir-analysis, r=compiler-errors Remove unnecessary sorts in `rustc_hir_analysis` A follow-up after #131140. Here the related objects are `IndexSet` so do not require a sort to stay stable. And they don't need to be `mut` anymore. r? ```@compiler-errors```
2024-10-15Rollup merge of #131675 - tdittr:update-unsupported-abi-message, ↵Matthias Krüger-3/+3
r=compiler-errors Update lint message for ABI not supported Tracking issue: #130260 As requested in https://github.com/rust-lang/rust/pull/128784#pullrequestreview-2364026550 I updated the error message. I could also change it to be the same message as if it was a hard error on a normal function: > "`{abi}` is not a supported ABI for the current target" Or would that get confusing when people try to google the error message? r? compiler-errors
2024-10-14Move trait bound modifiers into hir::PolyTraitRefMichael Goulet-1/+1
2024-10-14Update lint message for ABI not supportedTamme Dittrich-3/+3
2024-10-12Rollup merge of #128784 - tdittr:check-abi-on-fn-ptr, r=compiler-errorsMatthias Krüger-11/+15
Check ABI target compatibility for function pointers Tracking issue: https://github.com/rust-lang/rust/issues/130260 Related tracking issue: #87678 Compatibility of an ABI for a target was previously only performed on function definitions and `extern` blocks. This PR adds it also to function pointers to be consistent. This might have broken some of the `tests/ui/` depending on the platform, so a try run seems like a good idea. Also this might break existing code, because we now emit extra errors. Does this require a crater run? # Example ```rust // build with: --target=x86_64-unknown-linux-gnu // These raise E0570 extern "thiscall" fn foo() {} extern "thiscall" { fn bar() } // This did not raise any error fn baz(f: extern "thiscall" fn()) { f() } ``` # Open Questions * [x] Should this report a future incompatibility warning like #87678 ? * [ ] Is this the best place to perform the check?
2024-10-11intrinsics.fmuladdf{16,32,64,128}: expose llvm.fmuladd.* semanticsJed Brown-0/+13
Add intrinsics `fmuladd{f16,f32,f64,f128}`. This computes `(a * b) + c`, to be fused if the code generator determines that (i) the target instruction set has support for a fused operation, and (ii) that the fused operation is more efficient than the equivalent, separate pair of `mul` and `add` instructions. https://llvm.org/docs/LangRef.html#llvm-fmuladd-intrinsic MIRI support is included for f32 and f64. The codegen_cranelift uses the `fma` function from libc, which is a correct implementation, but without the desired performance semantic. I think this requires an update to cranelift to expose a suitable instruction in its IR. I have not tested with codegen_gcc, but it should behave the same way (using `fma` from libc).
2024-10-11Auto merge of #131045 - compiler-errors:remove-unnamed_fields, r=wesleywiserbors-56/+0
Retire the `unnamed_fields` feature for now `#![feature(unnamed_fields)]` was implemented in part in #115131 and #115367, however work on that feature has (afaict) stalled and in the mean time there have been some concerns raised (e.g.[^1][^2]) about whether `unnamed_fields` is worthwhile to have in the language, especially in its current desugaring. Because it represents a compiler implementation burden including a new kind of anonymous ADT and additional complication to field selection, and is quite prone to bugs today, I'm choosing to remove the feature. However, since I'm not one to really write a bunch of words, I'm specifically *not* going to de-RFC this feature. This PR essentially *rolls back* the state of this feature to "RFC accepted but not yet implemented"; however if anyone wants to formally unapprove the RFC from the t-lang side, then please be my guest. I'm just not totally willing to summarize the various language-facing reasons for why this feature is or is not worthwhile, since I'm coming from the compiler side mostly. Fixes #117942 Fixes #121161 Fixes #121263 Fixes #121299 Fixes #121722 Fixes #121799 Fixes #126969 Fixes #131041 Tracking: * https://github.com/rust-lang/rust/issues/49804 [^1]: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Unnamed.20struct.2Funion.20fields [^2]: https://github.com/rust-lang/rust/issues/49804#issuecomment-1972619108
2024-10-10Don't fire refinement lint if there are errorsMichael Goulet-0/+4
2024-10-10Clarify implicit captures for RPITITMichael Goulet-9/+16
2024-10-06Remove unnecessary sorts in `rustc_hir_analysis`.ismailarilik-4/+1
This is an attempt to gain the performance loss after the PR #131140. Here the related objects are `IndexSet` so do not require a sort to stay stable.
2024-10-04WfCheck opaques.Camille GILLOT-12/+18
2024-10-04rm `ItemKind::OpaqueTy`Noah Lev-11/+7
This introduce an additional collection of opaques on HIR, as they can no longer be listed using the free item list.
2024-10-04Rollup merge of #131202 - Urgau:wide-ptrs-compiler, r=jieyouxuGuillaume Gomez-1/+1
Use wide pointers consistenly across the compiler This PR replace every use of "fat pointer" for the more recent "wide pointer" terminology. Since some time T-lang as preferred the "wide pointer" terminology, as can be seen on [the last RFCs](https://github.com/search?q=repo%3Arust-lang%2Frfcs+%22wide+pointer%22&type=code), on some [lints](https://doc.rust-lang.org/rustc/lints/listing/warn-by-default.html#ambiguous-wide-pointer-comparisons), but also in [the reference](https://doc.rust-lang.org/stable/reference/expressions/operator-expr.html?highlight=wide%20pointer#pointer-to-pointer-cast). Currently we have a [mix of both](https://github.com/search?q=repo%3Arust-lang%2Frust+%22wide+pointer%22&type=code) (including in error messages), which isn't great, but with this PR no more. r? `@jieyouxu` (feel free to re-roll)
2024-10-04Use wide pointers consistenly across the compilerUrgau-1/+1
2024-10-03Rollup merge of #131183 - compiler-errors:opaque-ty-origin, r=estebankMatthias Krüger-10/+10
Refactoring to `OpaqueTyOrigin` Pulled out of a larger PR that uses these changes to do cross-crate encoding of opaque origin, so we can use them for edition 2024 migrations. These changes should be self-explanatory on their own, tho 😄
2024-10-02Move in_trait into OpaqueTyOriginMichael Goulet-7/+7
2024-10-02Use named fields for OpaqueTyOriginMichael Goulet-10/+10
2024-10-02Handle `rustc-hir-analysis` cases of `rustc::potential_query_instability` lintismailarilik-10/+10
2024-10-01Remove unnamed field featureMichael Goulet-56/+0
2024-09-29fix(hir_analysis/wfcheck): don't leak {type error}Barrett Ray-5/+12
avoid `{type error}` being leaked in user-facing messages, particularly when using the `adt_const_params` feature
2024-09-25Compiler: Rename "object safe" to "dyn compatible"León Orell Valerian Liehr-5/+6
2024-09-23Check ABI target compatibility for function pointersTamme Dittrich-11/+15
This check was previously only performed on functions not function pointers. Co-authored-by: Folkert <folkert@folkertdev.nl>
2024-09-22Reformat using the new identifier sorting from rustfmtMichael Goulet-103/+77
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-04 05:57:49 +0000