summary refs log tree commit diff
path: root/compiler/rustc_mir/src/monomorphize
AgeCommit message (Collapse)AuthorLines
2021-04-29Implement RFC 1260 with feature_name `imported_main`.Charles Lew-2/+2
2021-04-20Add an attribute to be able to configure the limitOli Scherer-1/+6
2021-04-20Implement a lint that highlights all moves larger than 1000 bytesOli Scherer-0/+37
2021-04-02fixMario Carneiro-1/+2
2021-04-02clarify wordingMario Carneiro-3/+6
2021-04-02Monomorphization doc fixMario Carneiro-2/+2
Only public items are monomorphization roots. This can be confirmed by noting that this program compiles: ```rust fn foo<T>() { if true { foo::<Option<T>>() } } fn bar() { foo::<()>() } ```
2021-04-02Auto merge of #83207 - oli-obk:valtree2, r=lcnrbors-2/+37
normalize mir::Constant differently from ty::Const in preparation for valtrees Valtrees are unable to represent many kind of constant values (this is on purpose). For constants that are used at runtime, we do not need a valtree representation and can thus use a different form of evaluation. In order to make this explicit and less fragile, I added a `fold_constant` method to `TypeFolder` and implemented it for normalization. Normalization can now, when it wants to eagerly evaluate a constant, normalize `mir::Constant` directly into a `mir::ConstantKind::Val` instead of relying on the `ty::Const` evaluation. In the future we can get rid of the `ty::Const` in there entirely and add our own `Unevaluated` variant to `mir::ConstantKind`. This would allow us to remove the `promoted` field from `ty::ConstKind::Unevaluated`, as promoteds can never occur in the type system. cc `@rust-lang/wg-const-eval` r? `@lcnr`
2021-03-31Cleanups and commentsJack Huey-3/+1
2021-03-31Some rebinds and dummysJack Huey-3/+5
2021-03-31Add a new normalization query just for mir constantsOli Scherer-1/+30
2021-03-31We should never see unevaluated type-level constants after monomorphization ↵Oli Scherer-1/+7
unless errors occurred
2021-03-30Run LLVM coverage instrumentation passes before optimization passesAmanieu d'Antras-7/+1
This matches the behavior of Clang and allows us to remove several hacks which were needed to ensure functions weren't optimized away before reaching the instrumentation pass.
2021-03-25Auto merge of #83307 - richkadel:cov-unused-functions-1.1, r=tmandrybors-1/+7
coverage bug fixes and optimization support Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to address multiple, somewhat related issues. Fixed a significant flaw in prior coverage solution: Every counter generated a new counter variable, but there should have only been one counter variable per function. This appears to have bloated .profraw files significantly. (For a small program, it increased the size by about 40%. I have not tested large programs, but there is anecdotal evidence that profraw files were way too large. This is a good fix, regardless, but hopefully it also addresses related issues. Fixes: #82144 Invalid LLVM coverage data produced when compiled with -C opt-level=1 Existing tests now work up to at least `opt-level=3`. This required a detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR when compiled with coverage, and a lot of trial and error with codegen adjustments. The biggest hurdle was figuring out how to continue to support coverage results for unused functions and generics. Rust's coverage results have three advantages over Clang's coverage results: 1. Rust's coverage map does not include any overlapping code regions, making coverage counting unambiguous. 2. Rust generates coverage results (showing zero counts) for all unused functions, including generics. (Clang does not generate coverage for uninstantiated template functions.) 3. Rust's unused functions produce minimal stubbed functions in LLVM IR, sufficient for including in the coverage results; while Clang must generate the complete LLVM IR for each unused function, even though it will never be called. This PR removes the previous hack of attempting to inject coverage into some other existing function instance, and generates dedicated instances for each unused function. This change, and a few other adjustments (similar to what is required for `-C link-dead-code`, but with lower impact), makes it possible to support LLVM optimizations. Fixes: #79651 Coverage report: "Unexecuted instantiation:..." for a generic function from multiple crates Fixed by removing the aforementioned hack. Some "Unexecuted instantiation" notices are unavoidable, as explained in the `used_crate.rs` test, but `-Zinstrument-coverage` has new options to back off support for either unused generics, or all unused functions, which avoids the notice, at the cost of less coverage of unused functions. Fixes: #82875 Invalid LLVM coverage data produced with crate brotli_decompressor Fixed by disabling the LLVM function attribute that forces inlining, if `-Z instrument-coverage` is enabled. This attribute is applied to Rust functions with `#[inline(always)], and in some cases, the forced inlining breaks coverage instrumentation and reports. FYI: `@wesleywiser` r? `@tmandry`
2021-03-23Add has_default to GenericParamDefKind::Constkadmin-1/+2
This currently creates a field which is always false on GenericParamDefKind for future use when consts are permitted to have defaults Update const_generics:default locations Previously just ignored them, now actually do something about them. Fix using type check instead of value Add parsing This adds all the necessary changes to lower const-generics defaults from parsing. Change P<Expr> to AnonConst This matches the arguments passed to instantiations of const generics, and makes it specific to just anonymous constants. Attempt to fix lowering bugs
2021-03-20update `const_eval_resolve`lcnr-2/+2
2021-03-20extract `ConstKind::Unevaluated` into a structlcnr-4/+4
2021-03-19coverage bug fixes and optimization supportRich Kadel-1/+7
Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to address multiple, somewhat related issues. Fixed a significant flaw in prior coverage solution: Every counter generated a new counter variable, but there should have only been one counter variable per function. This appears to have bloated .profraw files significantly. (For a small program, it increased the size by about 40%. I have not tested large programs, but there is anecdotal evidence that profraw files were way too large. This is a good fix, regardless, but hopefully it also addresses related issues. Fixes: #82144 Invalid LLVM coverage data produced when compiled with -C opt-level=1 Existing tests now work up to at least `opt-level=3`. This required a detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR when compiled with coverage, and a lot of trial and error with codegen adjustments. The biggest hurdle was figuring out how to continue to support coverage results for unused functions and generics. Rust's coverage results have three advantages over Clang's coverage results: 1. Rust's coverage map does not include any overlapping code regions, making coverage counting unambiguous. 2. Rust generates coverage results (showing zero counts) for all unused functions, including generics. (Clang does not generate coverage for uninstantiated template functions.) 3. Rust's unused functions produce minimal stubbed functions in LLVM IR, sufficient for including in the coverage results; while Clang must generate the complete LLVM IR for each unused function, even though it will never be called. This PR removes the previous hack of attempting to inject coverage into some other existing function instance, and generates dedicated instances for each unused function. This change, and a few other adjustments (similar to what is required for `-C link-dead-code`, but with lower impact), makes it possible to support LLVM optimizations. Fixes: #79651 Coverage report: "Unexecuted instantiation:..." for a generic function from multiple crates Fixed by removing the aforementioned hack. Some "Unexecuted instantiation" notices are unavoidable, as explained in the `used_crate.rs` test, but `-Zinstrument-coverage` has new options to back off support for either unused generics, or all unused functions, which avoids the notice, at the cost of less coverage of unused functions. Fixes: #82875 Invalid LLVM coverage data produced with crate brotli_decompressor Fixed by disabling the LLVM function attribute that forces inlining, if `-Z instrument-coverage` is enabled. This attribute is applied to Rust functions with `#[inline(always)], and in some cases, the forced inlining breaks coverage instrumentation and reports.
2021-03-18Rollup merge of #83080 - tmiasko:inline-coverage, r=wesleywiserDylan DPC-0/+25
Make source-based code coverage compatible with MIR inlining When codegenning code coverage use the instance that coverage data was originally generated for, to ensure basic level of compatibility with MIR inlining. Fixes #83061
2021-03-15Functions inlined into reachable functions are reachableTomasz Miąsko-0/+25
Consider functions to be reachable for code coverage purposes, either when they reach the code generation directly, or indirectly as inlined part of another function.
2021-03-12Prepare mir::Constant for ty::Const only supporting valtreesOli Scherer-1/+1
2021-03-04Fixes -Zpolymorphize for src/test/ui/const-generics/auxiliary/crayte.rsOli Scherer-9/+39
2021-03-04Spread tracing instrumentation into the polymorphization logicOli Scherer-33/+27
2021-02-24Use log level to control partitioning debug outputTomasz Miąsko-6/+15
2021-02-15Only store a LocalDefId in hir::ImplItem.Camille GILLOT-2/+1
2021-02-15Only store a LocalDefId in hir::Item.Camille GILLOT-20/+15
Items are guaranteed to be HIR owner.
2021-02-15Use an ItemId inside mir::GlobalAsm.Camille GILLOT-4/+4
2021-01-15Rollup merge of #80944 - LingMan:map_or, r=nagisaYuki Okushi-2/+1
Use Option::map_or instead of `.map(..).unwrap_or(..)` ``@rustbot`` modify labels +C-cleanup +T-compiler
2021-01-14Use Option::map_or instead of `.map(..).unwrap_or(..)`LingMan-2/+1
2021-01-14Rollup merge of #80969 - camelid:monomorph-ice-msg, r=nagisaMara Bos-1/+1
Use better ICE message when no MIR is available The ICE message is somewhat confusing and overly specific - the issue is that there's no MIR available. This should make debugging these ICEs easier since the error tells you what's actually wrong, not what it was trying to do when it failed. cc https://github.com/rust-lang/rust/pull/80952#issuecomment-759198841 cc `````@jyn514`````
2021-01-12Use better ICE message when no MIR is availableCamelid-1/+1
The ICE message is somewhat confusing and overly specific - the issue is that there's no MIR available. This should make debugging these ICEs easier since the error tells you what's actually wrong, not what it was trying to do when it failed. cc https://github.com/rust-lang/rust/pull/80952#issuecomment-759198841
2021-01-13Auto merge of #79322 - jyn514:refactor-impl, r=estebankbors-3/+3
Separate out a `hir::Impl` struct This makes it possible to pass the `Impl` directly to functions, instead of having to pass each of the many fields one at a time. It also simplifies matches in many cases. See `rustc_save_analysis::dump_visitor::process_impl` or `rustdoc::clean::clean_impl` for a good example of how this makes `impl`s easier to work with. r? `@petrochenkov` maybe?
2021-01-12Separate out a `hir::Impl` structJoshua Nelson-3/+3
This makes it possible to pass the `Impl` directly to functions, instead of having to pass each of the many fields one at a time. It also simplifies matches in many cases.
2021-01-04Adjust importsoli-3/+3
2021-01-04Polymorphization should look at the runtime MIR of `const fn`oli-5/+4
2021-01-04Differentiate between the availability of ctfe MIR and runtime MIRoli-4/+15
2021-01-04Keep an unoptimized duplicate of `const fn` aroundoli-1/+4
This allows CTFE to reliably detect UB, as otherwise optimizations may hide UB.
2020-11-26Remove ForeignMod struct.Camille GILLOT-1/+1
2020-11-26Store ForeignItem in a side table.Camille GILLOT-0/+2
2020-11-17Auto merge of #78779 - LeSeulArtichaut:ty-visitor-return, r=oli-obkbors-4/+6
Introduce `TypeVisitor::BreakTy` Implements MCP rust-lang/compiler-team#383. r? `@ghost` cc `@lcnr` `@oli-obk` ~~Blocked on FCP in rust-lang/compiler-team#383.~~
2020-11-16compiler: fold by valueBastian Kauschke-3/+3
2020-11-14Set the default `BreakTy` to `!`LeSeulArtichaut-0/+2
2020-11-14Introduce `TypeVisitor::BreakTy`LeSeulArtichaut-4/+4
2020-11-10Rollup merge of #78875 - petrochenkov:cleantarg, r=Mark-SimulacrumJonas Schievink-1/+1
rustc_target: Further cleanup use of target options Follow up to https://github.com/rust-lang/rust/pull/77729. Implements items 2 and 4 from the list in https://github.com/rust-lang/rust/pull/77729#issue-500228243. The first commit collapses uses of `target.options.foo` into `target.foo`. The second commit renames some target options to avoid tautology: `target.target_endian` -> `target.endian` `target.target_c_int_width` -> `target.c_int_width` `target.target_os` -> `target.os` `target.target_env` -> `target.env` `target.target_vendor` -> `target.vendor` `target.target_family` -> `target.os_family` `target.target_mcount` -> `target.mcount` r? `@Mark-Simulacrum`
2020-11-08Collapse all uses of `target.options.foo` into `target.foo`Vadim Petrochenkov-1/+1
with an eye on merging `TargetOptions` into `Target`. `TargetOptions` as a separate structure is mostly an implementation detail of `Target` construction, all its fields logically belong to `Target` and available from `Target` through `Deref` impls.
2020-11-06inliner: Use substs_for_mir_bodyTomasz Miąsko-5/+5
Changes from 68965 extended the kind of instances that are being inlined. For some of those, the `instance_mir` returns a MIR body that is already expressed in terms of the types found in substitution array, and doesn't need further substitution. Use `substs_for_mir_body` to take that into account.
2020-10-30Remove implicit `Continue` typeLeSeulArtichaut-4/+4
2020-10-30Use `ControlFlow::is{break,continue}`LeSeulArtichaut-1/+1
2020-10-30TypeVisitor: use `ControlFlow` in rustc_{mir,privacy,traits,typeck}LeSeulArtichaut-17/+28
2020-10-15Replace target.target with target and target.ptr_width with target.pointer_widthest31-1/+1
Preparation for a subsequent change that replaces rustc_target::config::Config with its wrapped Target. On its own, this commit breaks the build. I don't like making build-breaking commits, but in this instance I believe that it makes review easier, as the "real" changes of this PR can be seen much more easily. Result of running: find compiler/ -type f -exec sed -i -e 's/target\.target\([)\.,; ]\)/target\1/g' {} \; find compiler/ -type f -exec sed -i -e 's/target\.target$/target/g' {} \; find compiler/ -type f -exec sed -i -e 's/target.ptr_width/target.pointer_width/g' {} \; ./x.py fmt
2020-10-10Use range instead of tuple of intsDániel Buga-9/+9
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-07 14:01:21 +0000