about summary refs log tree commit diff
path: root/compiler/rustc_middle
AgeCommit message (Collapse)AuthorLines
2021-03-28Rollup merge of #83526 - klensy:lazy-too, r=petrochenkovYuki Okushi-4/+5
lazily calls some fns Replaced some fn's with it's lazy variants.
2021-03-27lazily calls some fnsklensy-4/+5
2021-03-26fix doc comment for `ty::Dynamiclcnr-1/+1
2021-03-26Auto merge of #83465 - michaelwoerister:safe-read_raw_bytes, r=cjgillotbors-2/+2
Allow for reading raw bytes from rustc_serialize::Decoder without unsafe code The current `read_raw_bytes` method requires using `MaybeUninit` and `unsafe`. I don't think this is necessary. Let's see if a safe interface has any performance drawbacks. This is a followup to #83273 and will make it easier to rebase #82183. r? `@cjgillot`
2021-03-25Auto merge of #82743 - jackh726:resolve-refactor, r=nikomatsakisbors-11/+21
Refactor rustc_resolve::late::lifetimes to resolve per-item There are some changes to tests that I'd like some feedback on; so this is still WIP. The reason behind this change will (hopefully) allow us to (as part of #76814) be able to essentially use the lifetime resolve code to resolve *all* late bound vars (including those of super traits). Currently, it only resolves those that are *syntactically* in scope. In #76814, I'm essentially finding that I would essentially have to redo the passing of bound vars through scopes (i.e. when instantiating a poly trait ref), and that's what this code does anyways. However, to be able to do this (ask super traits what bound vars are in scope), we have to be able to resolve items separately. The first commit is actually partially orthogonal. Essentially removing one use of late bound debruijn indices. Not exactly sure who would be best to review here. Let r? `@nikomatsakis`
2021-03-25Auto merge of #83424 - cjgillot:noparam, r=lcnrbors-20/+2
GenericParam does not need to be a HIR owner. The special case is not required. Universal impl traits design to regular generic parameters, and their content is owned by the enclosing item. Existential (and opaque) impl traits generate their own enclosing item, and are collected through it.
2021-03-25Allow for reading raw bytes from rustc_serialize::Decoder without unsafe code.Michael Woerister-2/+2
2021-03-25Auto merge of #83307 - richkadel:cov-unused-functions-1.1, r=tmandrybors-6/+20
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-24Review commentsJack Huey-4/+14
2021-03-24resolve late lifetimes by itemJack Huey-10/+10
This reverts commit 22ae20733515d710c1134600bc1e29cdd76f6b9b.
2021-03-23GenericParam does not need to be a HIR owner.Camille GILLOT-20/+2
2021-03-23Update with commentskadmin-2/+2
2021-03-23Update with commentskadmin-4/+5
A bunch of nits fixed, and a new test for pretty printing the AST.
2021-03-23Add query for const_param_defaultkadmin-13/+31
2021-03-23progress, stuff compiles nowlcnr-1/+9
2021-03-23Add has_default to GenericParamDefKind::Constkadmin-24/+29
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-22Auto merge of #79278 - mark-i-m:stabilize-or-pattern, r=nikomatsakisbors-1/+1
Stabilize or_patterns (RFC 2535, 2530, 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177
2021-03-22Auto merge of #83376 - Dylan-DPC:rollup-s2fsjwj, r=Dylan-DPCbors-2/+5
Rollup of 7 pull requests Successful merges: - #82374 (Add license metadata for std dependencies) - #82683 (Document panicking cases for integer division and remainder) - #83272 (Clarify non-exact length in the Iterator::take documentation) - #83338 (Fix test for #82270) - #83351 (post-drop-elab check-const: explain why we still check qualifs) - #83367 (Improve error message for unassigned query provider) - #83372 (SplitInclusive is public API) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-03-22Rollup merge of #83367 - richkadel:query-err-msg, r=jyn514Dylan DPC-2/+5
Improve error message for unassigned query provider Fixes: #83122 r? `@jyn514` This implements the change we agreed on. Thanks!
2021-03-22Auto merge of #83273 - cjgillot:endecode, r=michaelwoeristerbors-50/+7
Simplify encoder and decoder Extracted from https://github.com/rust-lang/rust/pull/83036 and https://github.com/rust-lang/rust/pull/82780.
2021-03-21Improve error message for unassigned query providerRich Kadel-2/+5
Fixes: 83122
2021-03-21Don't compute optimized PointerKind for unoptimized buildsNikita Popov-17/+24
This saves us both the Freeze/Unpin queries, and avoids placing noalias attributes, which have a compile-time impact on LLVM even in optnone builds (due to always_inline functions).
2021-03-21Don't consider !Unpin references as noaliasNikita Popov-3/+56
Such structures may contain self-references, in which case the same location may be accessible through a pointer that is not based-on the noalias pointer. This is still grey area as far as language semantics are concerned, but checking for !Unpin as an indicator for self-referential sturctures seems like a good approach for the meantime.
2021-03-21Move decision aboute noalias into codegen_llvmNikita Popov-20/+11
The frontend shouldn't be deciding whether or not to use mutable noalias attributes, as this is a pure LLVM concern. Only provide the necessary information and do the actual decision in codegen_llvm.
2021-03-21Rollup merge of #83040 - lcnr:unused-ct-substs, r=oli-obkDylan DPC-39/+54
extract `ConstKind::Unevaluated` into a struct r? `@oli-obk`
2021-03-21Rollup merge of #82707 - BoxyUwU:errooaaar, r=oli-obkDylan DPC-2/+19
const_evaluatable_checked: Stop eagerly erroring in `is_const_evaluatable` Fixes #82279 We don't want to be emitting errors inside of is_const_evaluatable because we may call this during selection where it should be able to fail silently There were two errors being emitted in `is_const_evaluatable`. The one causing the compile error in #82279 was inside the match arm for `FailureKind::MentionsParam` but I moved the other error being emitted too since it made things cleaner imo The `NotConstEvaluatable` enum \*should\* have a fourth variant for when we fail to evaluate a concrete const, e.g. `0 - 1` but that cant happen until #81339 cc `@oli-obk` `@lcnr` r? `@nikomatsakis`
2021-03-20update `const_eval_resolve`lcnr-7/+6
2021-03-20extract `ConstKind::Unevaluated` into a structlcnr-32/+48
2021-03-20Auto merge of #82919 - bstrie:stabchar, r=dtolnaybors-1/+0
Stabilize `assoc_char_funcs` and `assoc_char_consts` Stabilizes the following associated items on `char`: * [`char::MAX`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.MAX) * [`char::REPLACEMENT_CHARACTER`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.REPLACEMENT_CHARACTER) * [`char::UNICODE_VERSION`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.UNICODE_VERSION) * [`char::decode_utf16`](https://doc.rust-lang.org/std/primitive.char.html#method.decode_utf16) * [`char::from_u32`](https://doc.rust-lang.org/std/primitive.char.html#method.from_u32) * [`char::from_u32_unchecked`](https://doc.rust-lang.org/std/primitive.char.html#method.from_u32_unchecked) * [`char::from_digit`](https://doc.rust-lang.org/std/primitive.char.html#method.from_digit) Closes #71763.
2021-03-19Stabilize `assoc_char_funcs` and `assoc_char_consts`bstrie-1/+0
2021-03-19stabilize or_patternsmark-1/+1
2021-03-19coverage bug fixes and optimization supportRich Kadel-6/+20
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-19Rollup merge of #83297 - oli-obk:why_bug_today_if_you_can_delay_to_tomorrow, ↵Dylan DPC-5/+9
r=petrochenkov Do not ICE on ty::Error as an error must already have been reported fixes #83253
2021-03-19Remove FingerprintEncoder/Decoder.Camille GILLOT-13/+0
2021-03-19Move raw bytes handling to Encoder/Decoder.Camille GILLOT-0/+6
2021-03-19Auto merge of #82951 - sexxi-goose:wr-mir-replace-methods2, r=nikomatsakisbors-34/+53
Replace closures_captures and upvar_capture with closure_min_captures Removed all uses of closures_captures and upvar_capture and refactored code to work with closure_min_captures. This also involved removing functions that were no longer needed like the bridge. Closes https://github.com/rust-lang/project-rfc-2229/issues/18 r? `@nikomatsakis`
2021-03-19Do not ICE on ty::Error as an error must already have been reportedOli Scherer-5/+9
2021-03-19Hash hir_owner in typeck resultsAman Arora-1/+3
2021-03-18Replace closures_captures and upvar_capture with closure_min_capturesJennifer Wills-35/+52
make changes to liveness to use closure_min_captures use different span borrow check uses new structures rename to CapturedPlace stop using upvar_capture in regionck remove the bridge cleanup from rebase + remove the upvar_capture reference from mutability_errors.rs remove line from livenes test make our unused var checking more consistent update tests adding more warnings to the tests move is_ancestor_or_same_capture to rustc_middle/ty update names to reflect the closures add FIXME check that all captures are immutable borrows before returning add surrounding if statement like the original move var out of the loop and rename Co-authored-by: Logan Mosier <logmosier@gmail.com> Co-authored-by: Roxane Fruytier <roxane.fruytier@hotmail.com>
2021-03-18Move IntEncodedWithFixedSize to rustc_serialize.Camille GILLOT-37/+1
2021-03-18Remove unwrap_none/expect_none from compiler/.Mara Bos-3/+7
2021-03-18Auto merge of #82868 - petrochenkov:bto, r=estebankbors-0/+1
Report missing cases of `bare_trait_objects` Fixes https://github.com/rust-lang/rust/issues/65371
2021-03-18hir: Preserve used syntax in `TyKind::TraitObject`Vadim Petrochenkov-0/+1
2021-03-18Rollup merge of #83080 - tmiasko:inline-coverage, r=wesleywiserDylan DPC-0/+8
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-17Auto merge of #83188 - petrochenkov:field, r=lcnrbors-2/+2
ast/hir: Rename field-related structures I always forget what `ast::Field` and `ast::StructField` mean despite working with AST for long time, so this PR changes the naming to less confusing and more consistent. - `StructField` -> `FieldDef` ("field definition") - `Field` -> `ExprField` ("expression field", not "field expression") - `FieldPat` -> `PatField` ("pattern field", not "field pattern") Various visiting and other methods working with the fields are renamed correspondingly too. The second commit reduces the size of `ExprKind` by boxing fields of `ExprKind::Struct` in preparation for https://github.com/rust-lang/rust/pull/80080.
2021-03-17Auto merge of #83090 - jackh726:bound_var_replacer_option, r=varkorbors-55/+53
Make functions passed to BoundVarReplacer be optional This means we can reuse the bound vars when we don't care to change them
2021-03-17Rollup merge of #83124 - cjgillot:iiib, r=petrochenkovYuki Okushi-3/+2
Do not insert impl_trait_in_bindings opaque definitions twice. The reference to the item already appears inside the `OpaqueDef`. It does not need to be repeated as a statement.
2021-03-16Auto merge of #82936 - oli-obk:valtree, r=RalfJung,lcnr,matthewjasperbors-162/+443
Implement (but don't use) valtree and refactor in preparation of use This PR does not cause any functional change. It refactors various things that are needed to make valtrees possible. This refactoring got big enough that I decided I'd want it reviewed as a PR instead of trying to make one huge PR with all the changes. cc `@rust-lang/wg-const-eval` on the following commits: * 2027184 implement valtree * eeecea9 fallible Scalar -> ScalarInt * 042f663 ScalarInt convenience methods cc `@eddyb` on ef04a6d cc `@rust-lang/wg-mir-opt` for cf1700c (`mir::Constant` can now represent either a `ConstValue` or a `ty::Const`, and it is totally possible to have two different representations for the same value)
2021-03-16Auto merge of #82536 - sexxi-goose:handle-patterns-take-2, r=nikomatsakisbors-0/+28
2229: Handle patterns within closures correctly when `capture_disjoint_fields` is enabled This PR fixes several issues related to handling patterns within closures when `capture_disjoint_fields` is enabled. 1. Matching is always considered a use of the place, even with `_` patterns 2. Compiler ICE when capturing fields in closures through `let` assignments To do so, we - Introduced new Fake Reads - Delayed use of `Place` in favor of `PlaceBuilder` - Ensured that `PlaceBuilder` can be resolved before attempting to extract `Place` in any of the pattern matching code Closes rust-lang/project-rfc-2229/issues/27 Closes rust-lang/project-rfc-2229/issues/24 r? `@nikomatsakis`
2021-03-16Update compiler/rustc_middle/src/ty/consts/valtree.rsOli Scherer-1/+1
Co-authored-by: Ralf Jung <post@ralfj.de>
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-09-30 16:09:37 +0000