about summary refs log tree commit diff
path: root/src/librustc_mir_build
AgeCommit message (Collapse)AuthorLines
2020-08-30mv compiler to compiler/mark-15311/+0
2020-08-27Auto merge of #75933 - Aaron1011:feature/closure-move-err, r=oli-obkbors-3/+3
Point to a move-related span when pointing to closure upvars Fixes #75904 When emitting move/borrow errors, we may point into a closure to indicate why an upvar is used in the closure. However, we use the 'upvar span', which is just an arbitrary usage of the upvar. If the upvar is used in multiple places (e.g. a borrow and a move), we may end up pointing to the borrow. If the overall error is a move error, this can be confusing. This PR tracks the span that caused an upvar to become captured by-value instead of by-ref (assuming that it's not a `move` closure). We use this span instead of the 'upvar' span when we need to point to an upvar usage during borrow checking.
2020-08-26Auto merge of #75893 - Dylan-DPC:fix/offset-to-u64, r=oli-obkbors-6/+6
change offset from u32 to u64 References #71696 r? @oli-obk (closed the earlier pr because the rebase got messed up)
2020-08-26Point to a move-related span when pointing to closure upvarsAaron Hill-3/+3
Fixes #75904 When emitting move/borrow errors, we may point into a closure to indicate why an upvar is used in the closure. However, we use the 'upvar span', which is just an arbitrary usage of the upvar. If the upvar is used in multiple places (e.g. a borrow and a move), we may end up pointing to the borrow. If the overall error is a move error, this can be confusing. This PR tracks the span that caused an upvar to become captured by-value instead of by-ref (assuming that it's not a `move` closure). We use this span instead of the 'upvar' span when we need to point to an upvar usage during borrow checking.
2020-08-24hir: consistent use and naming of lang itemsDavid Wood-13/+6
This commit adjusts the naming of various lang items so that they are consistent and don't include prefixes containing the target or "LangItem". In addition, lang item variants are no longer exported from the `lang_items` module. Signed-off-by: David Wood <david@davidtw.co>
2020-08-23 change offset from u32 to u64DPC-6/+6
2020-08-22Use smaller def span for functionsAaron Hill-8/+21
Currently, the def span of a funtion encompasses the entire function signature and body. However, this is usually unnecessarily verbose - when we are pointing at an entire function in a diagnostic, we almost always want to point at the signature. The actual contents of the body tends to be irrelevant to the diagnostic we are emitting, and just takes up additional screen space. This commit changes the `def_span` of all function items (freestanding functions, `impl`-block methods, and `trait`-block methods) to be the span of the signature. For example, the function ```rust pub fn foo<T>(val: T) -> T { val } ``` now has a `def_span` corresponding to `pub fn foo<T>(val: T) -> T` (everything before the opening curly brace). Trait methods without a body have a `def_span` which includes the trailing semicolon. For example: ```rust trait Foo { fn bar(); }``` the function definition `Foo::bar` has a `def_span` of `fn bar();` This makes our diagnostic output much shorter, and emphasizes information that is relevant to whatever diagnostic we are reporting. We continue to use the full span (including the body) in a few of places: * MIR building uses the full span when building source scopes. * 'Outlives suggestions' use the full span to sort the diagnostics being emitted. * The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]` attribute points the entire scope body. * The 'unconditional recursion' lint uses the full span to show additional context for the recursive call. All of these cases work only with local items, so we don't need to add anything extra to crate metadata.
2020-08-17rust_ast::ast => rustc_astUjjwal Sharma-6/+6
2020-08-15replaced log with tracingGurpreet Singh-2/+2
2020-08-14Rollup merge of #75448 - lcnr:rn-as_local_hir_id, r=davidtwcoTyler Mandry-5/+5
merge `as_local_hir_id` with `local_def_id_to_hir_id` `as_local_hir_id` was defined as just calling `local_def_id_to_hir_id` and I think that having two different ways to call the same method is somewhat confusing. Don't really care about which of these 2 methods we want to keep. Does this require an MCP, considering that these methods are fairly frequently used?
2020-08-13merge `as_local_hir_id` with `local_def_id_to_hir_id`Bastian Kauschke-5/+5
2020-08-11Revert "Suppress debuginfo on naked function arguments"Nathaniel McCallum-11/+1
This reverts commit 25670749b44a9c7a4cfd3fbf780bbe3344a9a6c5. This commit does not actually fix the problem. It merely removes the name of the argument from the LLVM output. Even without the name, Rust codegen still spills the (nameless) variable onto the stack which is the root cause. The root cause is solved in the next commit.
2020-08-09rustc_mir_build: use IndexMap in TestKind::SwitchIntJosh Stone-23/+17
2020-08-08Eliminate the `SessionGlobals` from `librustc_ast`.Nicholas Nethercote-3/+2
By moving `{known,used}_attrs` from `SessionGlobals` to `Session`. This means they are accessed via the `Session`, rather than via TLS. A few `Attr` methods and `librustc_ast` functions are now methods of `Session`. All of this required passing a `Session` to lots of functions that didn't already have one. Some of these functions also had arguments removed, because those arguments could be accessed directly via the `Session` argument. `contains_feature_attr()` was dead, and is removed. Some functions were moved from `librustc_ast` elsewhere because they now need to access `Session`, which isn't available in that crate. - `entry_point_type()` --> `librustc_builtin_macros` - `global_allocator_spans()` --> `librustc_metadata` - `is_proc_macro_attr()` --> `Session`
2020-08-08Remove some unnecessary uses of `Option`.Nicholas Nethercote-1/+1
These arguments are never `None`.
2020-08-02fix typosliuzhenyu-1/+1
2020-08-01Auto merge of #74726 - oli-obk:tracing, r=Mark-Simulacrumbors-1/+1
Move from `log` to `tracing` The only visible change is that we now get timestamps in our logs: ``` Jul 24 18:41:01.065 TRACE rustc_mir::transform::const_prop: skipping replace of Rvalue::Use(const () because it is already a const Jul 24 18:41:01.065 TRACE rustc_mir::transform::const_prop: propagated into _2 Jul 24 18:41:01.065 TRACE rustc_mir::transform::const_prop: visit_constant: const () ``` This PR was explicitly designed to be as low-impact as possible. We can now move to using the name `tracing` insteads of `log` on a crate-by-crate basis and use any of the other tracing features where desirable. As far as I can tell this will allow tools to seamlessly keep working (since they are using `rustc_driver::init_log...`). This is the first half of step 1 of the accepted `tracing` MCP (https://github.com/rust-lang/compiler-team/issues/331)
2020-07-31Rename HAIR to THIR (Typed HIR).Valentin Lazureanu-89/+96
2020-07-31Move from `log` to `tracing`Oliver Scherer-1/+1
2020-07-31Auto merge of #65989 - Aaron1011:fix/normalize-param-env, r=nikomatsakisbors-1/+1
Normalize all opaque types when converting ParamEnv to Reveal::All When we normalize a type using a ParamEnv with a reveal mode of RevealMode::All, we will normalize opaque types to their underlying types (e.g. `type MyOpaque = impl Foo` -> `StructThatImplsFoo`). However, the ParamEnv may still have predicates referring to the un-normalized opaque type (e.g. `<T as MyTrait<MyOpaque>>`). This can cause trait projection to fail, since a type containing normalized opaque types will not match up with the un-normalized type in the `ParamEnv`. To fix this, we now explicitly normalize all opaque types in caller_bounds of a `ParamEnv` when changing its mode to `RevealMode::All`. This ensures that all predicatse will refer to the underlying types of any opaque types involved, allowing them to be matched up properly during projection. To reflect the fact that normalization is occuring, `ParamEnv::with_reveal_all` is renamed to `ParamEnv::with_reveal_all_normalized` Fixes #65918
2020-07-30Rollup merge of #74934 - nbdd0121:issue-73976, r=ecstatic-morseManish Goregaokar-1/+7
Improve diagnostics when constant pattern is too generic This PR is a follow-up to PR #74538 and issue #73976 When constants queries Layout, TypeId or type_name of a generic parameter, instead of emitting `could not evaluate constant pattern`, we will instead emit a more detailed message `constant pattern depends on a generic parameter`.
2020-07-30Auto merge of #74105 - npmccallum:naked, r=matthewjasperbors-1/+11
Suppress debuginfo on naked function arguments A function that has no prologue cannot be reasonably expected to support debuginfo. In fact, the existing code (before this patch) would generate invalid instructions that caused crashes. We can solve this easily by just not emitting the debuginfo in this case. Fixes https://github.com/rust-lang/rust/issues/42779 cc https://github.com/rust-lang/rust/issues/32408
2020-07-30Improve diagnostics when constant pattern is too genericGary Guo-1/+7
2020-07-27Suppress debuginfo on naked function argumentsNathaniel McCallum-1/+11
A function that has no prologue cannot be reasonably expected to support debuginfo. In fact, the existing code (before this patch) would generate invalid instructions that caused crashes. We can solve this easily by just not emitting the debuginfo in this case. Fixes https://github.com/rust-lang/rust/issues/42779 cc https://github.com/rust-lang/rust/issues/32408
2020-07-26Auto merge of #74708 - kanru:issue-74564, r=davidtwcobors-1/+6
Ensure stack when type checking and building MIR for large if expressions Fixes #74564
2020-07-26Auto merge of #74664 - pnadon:Miri-rename-undef-uninit, r=RalfJungbors-1/+1
Miri rename undef uninit Renamed parts of code within the `librustc_middle/mir/interpret/` directory. Related issue [#71193](https://github.com/rust-lang/rust/issues/71193)
2020-07-25Ensure stack when type checking and building MIR for large if expressionsKan-Ru Chen-1/+6
2020-07-24Rollup merge of #74703 - tmandry:issue-74047, r=oli-obkYuki Okushi-5/+0
Fix ICE while building MIR with type errors See https://github.com/rust-lang/rust/issues/74047#issuecomment-663290913 for background. Replacing a binding with `PatKind::Wild` (introduced in #51789 and later refactored in #67439) caused an ICE downstream while building MIR. I noticed that taking this code out no longer triggers the ICEs it was added to prevent. I'm not sure what else changed, or if this change is _correct_, but it does seem to be passing ui tests at least. r? @oli-obk cc @estebank Fixes #74047.
2020-07-23Fix ICE while building MIR with type errorsTyler Mandry-5/+0
Fixes #74047.
2020-07-22renamed ScalarMaybeUninit::not_undef to check_initPhilippe Nadon-1/+1
Renamed the function ScalarMaybeUninit::not_undef to ScalarMaybeUninit::check_init in the file src/librustc_middle/mir/interpret/value.rs, to reflect changes in terminology used. Related issue rust-lang#71193
2020-07-22Normalize opaque types when converting `ParamEnv` to `Reveal::All`Aaron Hill-1/+1
Fixes #65918
2020-07-21fetch -> lookupBastian Kauschke-1/+4
2020-07-21`try_update` -> `try_upgrade`Bastian Kauschke-1/+1
2020-07-21remove some const arg in ty dep path boilerplateBastian Kauschke-8/+3
2020-07-17Rollup merge of #74411 - jonas-schievink:unbreak-mir, r=matthewjasperManish Goregaokar-9/+11
Don't assign `()` to `!` MIR locals Implements the fix described in https://github.com/rust-lang/rust/issues/73860#issuecomment-651731893. Fixes https://github.com/rust-lang/rust/issues/73860 r? @matthewjasper
2020-07-17Auto merge of #72983 - Lezzz:rename-typeck, r=nikomatsakisbors-108/+124
Rename TypeckTables to TypeckResults. Originally suggested by @eddyb.
2020-07-17Rename TypeckTables to TypeckResults.Valentin Lazureanu-108/+124
2020-07-16apply bootstrap cfgsMark Rousskov-1/+0
2020-07-16Don't assign `()` to `!` MIR localsJonas Schievink-9/+11
2020-07-15WithOptConstParam::dummy -> WithOptConstParam::unknownBastian Kauschke-2/+2
2020-07-15improve namingBastian Kauschke-8/+12
2020-07-15update const arg queriesBastian Kauschke-7/+3
2020-07-15const generics work!Bastian Kauschke-18/+31
2020-07-15continue mir pipelineBastian Kauschke-1/+1
2020-07-15ConstKind::UnevaluatedBastian Kauschke-2/+6
2020-07-09Rollup merge of #74070 - eddyb:forall-tcx-providers, r=nikomatsakisManish Goregaokar-1/+1
Use for<'tcx> fn pointers in Providers, instead of having Providers<'tcx>. In order to work around normalization-under-HRTB (for `provide!` in `rustc_metadata`), we ended up with this: ```rust struct Providers<'tcx> { type_of: fn(TyCtxt<'tcx>, DefId) -> Ty<'tcx>, // ... } ``` But what I initially wanted to do, IIRC, was this: ```rust struct Providers { type_of: for<'tcx> fn(TyCtxt<'tcx>, DefId) -> Ty<'tcx>, // ... } ``` This PR moves to the latter, for the simple reason that only the latter allows keeping a `Providers` value, or a subset of its `fn` pointer fields, around in a `static` or `thread_local!`, which can be really useful for custom drivers that override queries. (@jyn514 and I came across a concrete usecase of that in `rustdoc`) The `provide!` macro in `rustc_metadata` is fixed by making the query key/value types available as type aliases under `ty::query::query_{keys,values}`, not just associated types (this is the first commit). r? @nikomatsakis
2020-07-06Rollup merge of #73969 - ↵Manish Goregaokar-1/+3
davidtwco:issue-73914-checkedadd-temp-generator-interior, r=matthewjasper mir: mark mir construction temporaries as internal Fixes #73914. This PR marks temporaries from MIR construction as internal such that they are skipped in `sanitize_witness` (where each MIR local is checked to have been contained within the generator interior computed during typeck). This resolves an ICE whereby the construction of checked addition introduced a `(u64, bool)` temporary which was not in the HIR and thus not in the generator interior. r? @matthewjasper
2020-07-05Rollup merge of #73973 - Nadrieril:fix-71977, r=matthewjasperManish Goregaokar-13/+39
Use `Span`s to identify unreachable subpatterns in or-patterns Fixes #71977
2020-07-05Use for<'tcx> fn pointers in Providers, instead of having Providers<'tcx>.Eduard-Mihai Burtescu-1/+1
2020-07-04Fix #71977Nadrieril-5/+31
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 09:25:49 +0000