about summary refs log tree commit diff
path: root/compiler/rustc_hir_analysis
AgeCommit message (Collapse)AuthorLines
2024-10-26Rollup merge of #132168 - fee1-dead-contrib:fxclean, r=compiler-errorsMatthias Krüger-30/+10
Effects cleanup - removed extra bits from predicates queries that are no longer needed in the new system - removed the need for `non_erasable_generics` to take in tcx and DefId, removed unused arguments in callers r? compiler-errors
2024-10-26Effects cleanupDeadbeef-30/+10
- removed extra bits from predicates queries that are no longer needed in the new system - removed the need for `non_erasable_generics` to take in tcx and DefId, removed unused arguments in callers
2024-10-25tcx.is_const_fn doesn't work the way it is described, remove itRalf Jung-1/+1
Then we can rename the _raw functions to drop their suffix, and instead explicitly use is_stable_const_fn for the few cases where that is really what you want.
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-72/+37
2024-10-24Implement const effect predicate in new solverMichael Goulet-34/+503
2024-10-24Remove associated type based effects logicMichael Goulet-216/+7
2024-10-24Rollup merge of #131756 - compiler-errors:deeply-normalize-type-err, r=lcnrStuart Cook-8/+12
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/+12
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-34/+36
2024-10-22Deduplicate handling of early-bound params in RTNMichael Goulet-22/+29
2024-10-22Simplify confusing ResolvedArg constructorsMichael Goulet-57/+46
2024-10-22Represent TraitBoundModifiers as distinct parts in HIRMichael Goulet-20/+18
2024-10-22Rollup merge of #131049 - compiler-errors:more-validation, r=spastorinoMatthias Krüger-2/+1
Validate args are correct for `UnevaluatedConst`, `ExistentialTraitRef`/`ExistentialProjection` For the `Existential*` ones, we have to do some adjustment to the args list to deal with the missing `Self` type, so we introduce a `debug_assert_existential_args_compatible` function to the interner as well.
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-21Auto merge of #131988 - matthiaskrgr:rollup-tx173wn, r=matthiaskrgrbors-21/+21
Rollup of 4 pull requests Successful merges: - #126588 (Added more scenarios where comma to be removed in the function arg) - #131728 (bootstrap: extract builder cargo to its own module) - #131968 (Rip out old effects var handling code from traits) - #131981 (Remove the `BoundConstness::NotConst` variant) r? `@ghost` `@rustbot` modify labels: rollup
2024-10-21Rollup merge of #131981 - compiler-errors:bound-constness, r=cjgillotMatthias Krüger-21/+21
Remove the `BoundConstness::NotConst` variant I find it easier to represent `BoundConstness::NotConst` as just `None` for some refactorings I'm doing.
2024-10-21Auto merge of #130950 - compiler-errors:yeet-eval, r=BoxyUwUbors-4/+6
Continue to get rid of `ty::Const::{try_}eval*` This PR mostly does: * Removes all of the `try_eval_*` and `eval_*` helpers from `ty::Const`, and replace their usages with `try_to_*`. * Remove `ty::Const::eval`. * Rename `ty::Const::normalize` to `ty::Const::normalize_internal`. This function is still used in the normalization code itself. * Fix some weirdness around the `TransmuteFrom` goal. I'm happy to split it out further; for example, I could probably land the first part which removes the helpers, or the changes to codegen which are more obvious than the changes to tools. r? BoxyUwU Part of https://github.com/rust-lang/rust/issues/130704
2024-10-20tweak hybrid predsMichael Goulet-18/+14
2024-10-20Remove the BoundConstness::NotConst variantMichael Goulet-21/+21
2024-10-20Inline lower_mono_bounds into lower_poly_boundsMichael Goulet-39/+17
2024-10-20Make LowerPolyBounds take an IntoIteratorMichael Goulet-5/+5
2024-10-20make unsupported_calling_conventions a hard errorRalf Jung-28/+17
2024-10-19Rollup merge of #131939 - compiler-errors:predicate-filter, r=fmeaseMatthias Krüger-95/+61
Get rid of `OnlySelfBounds` We turn `PredicateFilter` into a newtyped bool called `OnlySelfBounds`. There's no reason to lose the information of the `PredicateFilter`, so let's just pass it all the way through.
2024-10-19Get rid of const eval_* and try_eval_* helpersMichael Goulet-4/+6
2024-10-19Use PredicateFilter instead of OnlySelfBoundsMichael Goulet-95/+61
2024-10-19Remove unnecessary constnessMichael Goulet-45/+16
2024-10-17Rollup merge of #128391 - cafce25:issue-128390, r=lcnrMatthias Krüger-5/+10
Change orphan hint from "only" to "any uncovered type inside..." Fix #128390
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-16Rollup merge of #131754 - compiler-errors:bivariance-bivariance, r=estebankUrgau-10/+50
Don't report bivariance error when nesting a struct with field errors into another struct We currently have logic to avoid reporting lifetime bivariance ("lifetime parameter ... is never used") errors when a struct has field resolution errors. However, this doesn't apply transitively. This PR implements a simple visitor to do so. This was reported [here](https://twitter.com/fasterthanlime/status/1846257921086165033) since a `derive(Deserialize, Serialize)` ends up generating helper structs which have bivariant lifetimes due to containing the offending struct (that's being derived on).
2024-10-16Auto merge of #131422 - GnomedDev:smallvec-predicate-obligations, ↵bors-5/+6
r=compiler-errors Use `ThinVec` for PredicateObligation storage ~~I noticed while profiling clippy on a project that a large amount of time is being spent allocating `Vec`s for `PredicateObligation`, and the `Vec`s are often quite small. This is an attempt to optimise this by using SmallVec to avoid heap allocations for these common small Vecs.~~ This PR turns all the `Vec<PredicateObligation>` into a single type alias while avoiding referring to `Vec` around it, then swaps the type over to `ThinVec<PredicateObligation>` and fixes the fallout. This also contains an implementation of `ThinVec::extract_if`, copied from `Vec::extract_if` and currently being upstreamed to https://github.com/Gankra/thin-vec/pull/66. This leads to a small (0.2-0.7%) performance gain in the latest perf run.
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-21/+22
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-7/+2
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-14improve error messages for `C-cmse-nonsecure-entry` functionsFolkert de Vries-67/+122
2024-10-14Move trait bound modifiers into hir::PolyTraitRefMichael Goulet-18/+19
2024-10-14Update lint message for ABI not supportedTamme Dittrich-3/+3
2024-10-12Rollup merge of #131239 - VulnBandit:trait-vulnerability, r=lcnrMatthias Krüger-35/+37
Don't assume traits used as type are trait objs in 2021 edition Fixes #127548 When you use a trait as a type, the compiler automatically assumes you meant to use a trait object, which is not always the case. This PR fixes the bug where you don't need a trait object, so the error message was changed to: ``` error[E0782]: expected a type, found a trait ``` Also fixes some ICEs: Fixes https://github.com/rust-lang/rust/issues/120241 Fixes https://github.com/rust-lang/rust/issues/120482 Fixes https://github.com/rust-lang/rust/issues/125512
2024-10-12Rollup merge of #128784 - tdittr:check-abi-on-fn-ptr, r=compiler-errorsMatthias Krüger-15/+37
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-12Swap Vec<PredicateObligation> to type aliasGnomedDev-5/+6
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).
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-04 13:12:42 +0000