summary refs log tree commit diff
path: root/compiler/rustc_smir/src
AgeCommit message (Collapse)AuthorLines
2024-11-20reduce false positives of tail-expr-drop-order from consumed valuesDing Xiang Fei-0/+4
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-19`InterpCx` store `TypingEnv` instead of a `ParamEnv`lcnr-2/+2
2024-11-18use `TypingEnv` when no `infcx` is availablelcnr-19/+41
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-07Rollup merge of #132131 - celinval:smir-crate-defs, r=compiler-errorsJubilee-3/+47
[StableMIR] API to retrieve definitions from crates Add functions to retrieve function definitions and static items from all crates (local and external). For external crates, we're still missing items from trait implementation and primitives. r? ````@compiler-errors:```` Do you know what is the best way to retrieve the associated items for primitives and trait implementations for external crates? Thanks!
2024-11-07[StableMIR] API to retrieve definitions from cratesCelina G. Val-3/+47
Add functions to retrieve function definitions and static items from all crates (local and external). For external crates, add a query to retrieve the number of defs in a foreign crate.
2024-11-04ty::BrK -> ty::BoundRegionKind::KMichael Goulet-6/+6
2024-11-04Remove the trivial constkind importsMichael Goulet-16/+16
2024-11-03compiler: Directly use rustc_abi in smir againJubilee Young-58/+58
2024-10-29compiler: `rustc_abi::Abi` => `BackendRepr`Jubilee Young-7/+7
The initial naming of "Abi" was an awful mistake, conveying wrong ideas about how psABIs worked and even more about what the enum meant. It was only meant to represent the way the value would be described to a codegen backend as it was lowered to that intermediate representation. It was never meant to mean anything about the actual psABI handling! The conflation is because LLVM typically will associate a certain form with a certain ABI, but even that does not hold when the special cases that actually exist arise, plus the IR annotations that modify the ABI. Reframe `rustc_abi::Abi` as the `BackendRepr` of the type, and rename `BackendRepr::Aggregate` as `BackendRepr::Memory`. Unfortunately, due to the persistent misunderstandings, this too is now incorrect: - Scattered ABI-relevant code is entangled with BackendRepr - We do not always pre-compute a correct BackendRepr that reflects how we "actually" want this value to be handled, so we leave the backend interface to also inject various special-cases here - In some cases `BackendRepr::Memory` is a "real" aggregate, but in others it is in fact using memory, and in some cases it is a scalar! Our rustc-to-backend lowering code handles this sort of thing right now. That will eventually be addressed by lifting duplicated lowering code to either rustc_codegen_ssa or rustc_target as appropriate.
2024-10-28stable_mir: Directly use types from rustc_abiJubilee Young-43/+31
2024-10-27compiler: Rename LayoutS to LayoutDataJubilee Young-1/+1
The last {UninternedType}S is in captivity. The galaxy is at peace.
2024-10-26Effects cleanupDeadbeef-4/+2
- 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-24Implement const effect predicate in new solverMichael Goulet-0/+3
2024-10-24Remove associated type based effects logicMichael Goulet-2/+1
2024-10-22Rollup merge of #131049 - compiler-errors:more-validation, r=spastorinoMatthias Krüger-11/+13
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-19Get rid of const eval_* and try_eval_* helpersMichael Goulet-1/+1
2024-10-06various fixes for `naked_asm!` implementationFolkert de Vries-0/+1
- fix for divergence - fix error message - fix another cranelift test - fix some cranelift things - don't set the NORETURN option for naked asm - fix use of naked_asm! in doc comment - fix use of naked_asm! in run-make test - use `span_bug` in unreachable branch
2024-09-30Validate ExistentialPredicate argsMichael Goulet-11/+13
2024-09-27Rollup merge of #130826 - fmease:compiler-mv-obj-safe-dyn-compat, ↵Matthias Krüger-2/+2
r=compiler-errors Compiler: Rename "object safe" to "dyn compatible" Completed T-lang FCP: https://github.com/rust-lang/lang-team/issues/286#issuecomment-2338905118. Tracking issue: https://github.com/rust-lang/rust/issues/130852 Excludes `compiler/rustc_codegen_cranelift` (to be filed separately). Includes Stable MIR. Regarding https://github.com/rust-lang/rust/labels/relnotes, I guess I will manually open a https://github.com/rust-lang/rust/labels/relnotes-tracking-issue since this change affects everything (compiler, library, tools, docs, books, everyday language). r? ghost
2024-09-25Compiler: Rename "object safe" to "dyn compatible"León Orell Valerian Liehr-2/+2
2024-09-24be even more precise about "cast" vs "coercion"Lukas Markeffsky-2/+2
2024-09-24unify dyn* coercions with other pointer coercionsLukas Markeffsky-1/+3
2024-09-23Check vtable projections for validity in miriMichael Goulet-2/+3
2024-09-22Reformat using the new identifier sorting from rustfmtMichael Goulet-12/+14
2024-09-21add `C-cmse-nonsecure-entry` ABIFolkert de Vries-0/+3
2024-09-03Auto merge of #129777 - nnethercote:unreachable_pub-4, r=Urgaubors-8/+9
Add `unreachable_pub`, round 4 A follow-up to #129732. r? `@Urgau`
2024-09-03Add `warn(unreachable_pub)` to `rustc_smir`.Nicholas Nethercote-8/+9
2024-09-02chore: Fix typos in 'compiler' (batch 2)Alexander Cyon-1/+1
2024-08-26Stop using a special inner body for the coroutine by-move body for async ↵Michael Goulet-2/+3
closures
2024-08-21Simplify some redundant field namesMichael Goulet-1/+1
2024-08-18rename AddressOf -> RawBorrow inside the compilerRalf Jung-1/+1
2024-08-09Shrink `TyKind::FnPtr`.Nicholas Nethercote-2/+7
By splitting the `FnSig` within `TyKind::FnPtr` into `FnSigTys` and `FnHeader`, which can be packed more efficiently. This reduces the size of the hot `TyKind` type from 32 bytes to 24 bytes on 64-bit platforms. This reduces peak memory usage by a few percent on some benchmarks. It also reduces cache misses and page faults similarly, though this doesn't translate to clear cycles or wall-time improvements on CI.
2024-07-29Reformat `use` declarations.Nicholas Nethercote-22/+27
The previous commit updated `rustfmt.toml` appropriately. This commit is the outcome of running `x fmt --all` with the new formatting options.
2024-07-17Avoid comments that describe multiple `use` items.Nicholas Nethercote-0/+1
There are some comments describing multiple subsequent `use` items. When the big `use` reformatting happens some of these `use` items will be reordered, possibly moving them away from the comment. With this additional level of formatting it's not really feasible to have comments of this type. This commit removes them in various ways: - merging separate `use` items when appropriate; - inserting blank lines between the comment and the first `use` item; - outright deletion (for comments that are relatively low-value); - adding a separate "top-level" comment. We also entirely skip formatting for four library files that contain nothing but `pub use` re-exports, where reordering would be painful.
2024-07-11Remove extern "wasm" ABINikita Popov-2/+0
Remove the unstable `extern "wasm"` ABI (`wasm_abi` feature tracked in #83788). As discussed in https://github.com/rust-lang/rust/pull/127513#issuecomment-2220410679 and following, this ABI is a failed experiment that did not end up being used for anything. Keeping support for this ABI in LLVM 19 would require us to switch wasm targets to the `experimental-mv` ABI, which we do not want to do. It should be noted that `Abi::Wasm` was internally used for two things: The `-Z wasm-c-abi=legacy` ABI that is still used by default on some wasm targets, and the `extern "wasm"` ABI. Despite both being `Abi::Wasm` internally, they were not the same. An explicit `extern "wasm"` additionally enabled the `+multivalue` feature. I've opted to remove `Abi::Wasm` in this patch entirely, instead of keeping it as an ABI with only internal usage. Both `-Z wasm-c-abi` variants are now treated as part of the normal C ABI, just with different different treatment in adjust_for_foreign_abi.
2024-07-08Auto merge of #113128 - WaffleLapkin:become_trully_unuwuable, r=oli-obk,RalfJungbors-0/+1
Support tail calls in mir via `TerminatorKind::TailCall` This is one of the interesting bits in tail call implementation — MIR support. This adds a new `TerminatorKind` which represents a tail call: ```rust TailCall { func: Operand<'tcx>, args: Vec<Operand<'tcx>>, fn_span: Span, }, ``` *Structurally* this is very similar to a normal `Call` but is missing a few fields: - `destination` — tail calls don't write to destination, instead they pass caller's destination to the callee (such that eventual `return` will write to the caller of the function that used tail call) - `target` — similarly to `destination` tail calls pass the caller's return address to the callee, so there is nothing to do - `unwind` — I _think_ this is applicable too, although it's a bit confusing - `call_source` — `become` forbids operators and is not created as a lowering of something else; tail calls always come from HIR (at least for now) It might be helpful to read the interpreter implementation to understand what `TailCall` means exactly, although I've tried documenting it too. ----- There are a few `FIXME`-questions still left, ideally we'd be able to answer them during review ':) ----- r? `@oli-obk` cc `@scottmcm` `@DrMeepster` `@JakobDegen`
2024-07-07Support tail calls in mir via `TerminatorKind::TailCall`Maybe Waffle-0/+1
2024-07-04Auto merge of #123781 - RalfJung:miri-fn-identity, r=oli-obkbors-1/+1
Miri function identity hack: account for possible inlining Having a non-lifetime generic is not the only reason a function can be duplicated. Another possibility is that the function may be eligible for cross-crate inlining. So also take into account the inlining attribute in this Miri hack for function pointer identity. That said, `cross_crate_inlinable` will still sometimes return true even for `inline(never)` functions: - when they are `DefKind::Ctor(..) | DefKind::Closure` -- I assume those cannot be `InlineAttr::Never` anyway? - when `cross_crate_inline_threshold == InliningThreshold::Always` so maybe this is still not quite the right criterion to use for function pointer identity.
2024-07-02Instance::resolve -> Instance::try_resolve, and other nitsMichael Goulet-1/+1
2024-07-02Miri function identity hack: account for possible inliningRalf Jung-1/+1
2024-06-28implement new effects desugaringDeadbeef-3/+5
2024-06-28Add method to get all attributes on a definitionAdwin White-2/+23
2024-06-28Support fetching `Attribute` of items.Adwin White-0/+19
2024-06-26Remove `f16` and `f128` ICE paths from smirTrevor Gross-2/+4
2024-06-24Split out IntoIterator and non-Iterator constructors for ↵Michael Goulet-1/+1
AliasTy/AliasTerm/TraitRef/projection
2024-06-21Add method to get `FnAbi` of function pointerAdwin White-0/+7
2024-06-20Add blank lines after module-level `//!` comments.Nicholas Nethercote-0/+2
Most modules have such a blank line, but some don't. Inserting the blank line makes it clearer that the `//!` comments are describing the entire module, rather than the `use` declaration(s) that immediately follows.
2024-06-16Rename InstanceDef -> InstanceKindMichael Goulet-21/+21
2024-06-15Rollup merge of #126410 - RalfJung:smir-const-operand, r=oli-obkGuillaume Gomez-5/+9
smir: merge identical Constant and ConstOperand types The first commit renames the const operand visitor functions on regular MIR to match the type name, that was forgotten in the original rename. The second commit changes stable MIR, fixing https://github.com/rust-lang/project-stable-mir/issues/71. Previously there were two different smir types for the MIR type `ConstOperand`, one used in `Operand` and one in `VarDebugInfoContents`. Maybe we should have done this with https://github.com/rust-lang/rust/pull/125967, so there's only a single breaking change... but I saw that PR too late. Fixes https://github.com/rust-lang/project-stable-mir/issues/71
2024-06-15Auto merge of #126518 - matthiaskrgr:rollup-wb70rzq, r=matthiaskrgrbors-13/+24
Rollup of 9 pull requests Successful merges: - #125829 (rustc_span: Add conveniences for working with span formats) - #126361 (Unify intrinsics body handling in StableMIR) - #126417 (Add `f16` and `f128` inline ASM support for `x86` and `x86-64`) - #126424 ( Also sort `crt-static` in `--print target-features` output) - #126428 (Polish `std::path::absolute` documentation.) - #126429 (Add `f16` and `f128` const eval for binary and unary operationations) - #126448 (End support for Python 3.8 in tidy) - #126488 (Use `std::path::absolute` in bootstrap) - #126511 (.mailmap: Associate both my work and my private email with me) r? `@ghost` `@rustbot` modify labels: rollup