about summary refs log tree commit diff
path: root/src/librustc_middle
AgeCommit message (Collapse)AuthorLines
2020-07-15decode stuffBastian Kauschke-3/+3
2020-07-15const generics work!Bastian Kauschke-16/+59
2020-07-15continue mir pipelineBastian Kauschke-17/+37
2020-07-15optimized_mirBastian Kauschke-3/+12
2020-07-15InstanceDef::ItemBastian Kauschke-18/+34
2020-07-15typeck all the tablesBastian Kauschke-0/+19
2020-07-15const_eval_resolveBastian Kauschke-7/+38
2020-07-15ConstKind::UnevaluatedBastian Kauschke-11/+23
2020-07-15begin using `WithOptParam`Bastian Kauschke-6/+39
2020-07-15introduce the query `opt_const_param_of`Bastian Kauschke-0/+19
2020-07-14Edit docs for rustc_middle::dep_graph::dep_nodepierwill-6/+8
Fixes some missing punctuation, and adds a blank line for a more concise summary.
2020-07-15Change `SymbolName::name` to a `&str`.Nicholas Nethercote-34/+51
This eliminates a bunch of `Symbol::intern()` and `Symbol::as_str()` calls, which is good, because they require locking the interner. Note that the unsafety in `from_cycle_error()` is identical to the unsafety on other adjacent impls.
2020-07-15Auto merge of #74175 - nnethercote:more-static-symbols, r=oli-obkbors-2/+1
More static symbols These commits add some more static symbols and convert lots of places to use them. r? @oli-obk
2020-07-15Remove lots of `Symbol::as_str()` calls.Nicholas Nethercote-2/+1
In various ways, such as changing functions to take a `Symbol` instead of a `&str`.
2020-07-14Rollup merge of #74228 - estebank:unsized-param, r=davidtwcoManish Goregaokar-3/+6
Provide structured suggestion on unsized fields and fn params * Suggest borrowing or boxing unsized fields * Suggest borrowing fn parameters * Remove some verbosity of unsized errors * Remove `on_unimplemented` note from `trait Sized` Fix #23286, fix #28653. r? @davidtwco
2020-07-14Suggest boxing or borrowing unsized fieldsEsteban Küber-1/+4
2020-07-14Suggest borrowing unsized argument typesEsteban Küber-2/+2
2020-07-14Rollup merge of #74227 - erikdesjardins:layun, r=estebankManish Goregaokar-3/+3
Remove an unwrap in layout computation A tiny improvement.
2020-07-11Rollup merge of #74240 - da-x:fix-74081, r=ManishearthManish Goregaokar-1/+1
Fix #74081 and add the test case from #74236
2020-07-11Rollup merge of #72920 - oli-obk:const_transmute, r=RalfJungManish Goregaokar-1/+1
Stabilize `transmute` in constants and statics but not const fn cc #53605 (leaving issue open so we can add `transmute` to `const fn` later) Previous attempt: #64011 r? @RalfJung cc @rust-lang/wg-const-eval
2020-07-11Fix try_print_visible_def_path_recur for opt_def_id usageDan Aloni-1/+1
This to fix #74081.
2020-07-11Stabilize `transmute` in constants and statics but not const fnOliver Scherer-1/+1
2020-07-10Rollup merge of #74162 - lcnr:ToPredicate-no-ref, r=varkorManish Goregaokar-13/+13
take self by value in ToPredicate
2020-07-10Rollup merge of #74127 - tamird:allowlist, r=oli-obkManish Goregaokar-11/+11
Avoid "whitelist" Other terms are more inclusive and precise.
2020-07-10Rollup merge of #73862 - oli-obk:const_array_to_slice, r=RalfJungManish Goregaokar-1/+1
Stabilize casts and coercions to `&[T]` in const fn Part of #64992 There was never a reason to not stabilize this, we just accidentally prevented them when we implemented the `min_const_fn` feature that gave us `const fn` on stable. This PR stabilizes these casts (which are already stable in `const` outside `const fn`), while keeping all other unsizing casts (so `T` -> `dyn Trait`) unstable within const fn. These casts have no forward compatibility concerns with any future features for const eval and users were able to use them under the `const_fn` feature gate already since at least the miri merger, possibly longer. r? @rust-lang/lang
2020-07-10Remove an unwrap in layout computationErik Desjardins-3/+3
2020-07-10Avoid "whitelist"Tamir Duberstein-11/+11
Other terms are more inclusive and precise.
2020-07-09Rollup merge of #74079 - nnethercote:session-globals, r=nikomatsakisManish Goregaokar-8/+7
Eliminate confusing "globals" terminology. There are some structures that are called "globals", but are they global to a compilation session, and not truly global. I have always found this highly confusing, so this commit renames them as "session globals" and adds a comment explaining things. Also, the commit fixes an unnecessary nesting of `set()` calls `src/librustc_errors/json/tests.rs` r? @Aaron1011
2020-07-09Rollup merge of #74070 - eddyb:forall-tcx-providers, r=nikomatsakisManish Goregaokar-20/+42
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-09Eliminate confusing "globals" terminology.Nicholas Nethercote-8/+7
There are some structures that are called "globals", but are they global to a compilation session, and not truly global. I have always found this highly confusing, so this commit renames them as "session globals" and adds a comment explaining things. Also, the commit fixes an unnecessary nesting of `set()` calls `src/librustc_errors/json/tests.rs`
2020-07-08ToPredicate by valueBastian Kauschke-13/+13
2020-07-08Add `reachable` and friends to `mir::traversal` moduleDylan MacKenzie-0/+17
2020-07-06Auto merge of #73978 - Mark-Simulacrum:shrink-paramenv, r=nnethercotebors-16/+115
Shrink ParamEnv to 16 bytes r? @nnethercote x.py check passes but I haven't tried running perf or tests
2020-07-05Rollup merge of #74057 - lcnr:expected_found, r=davidtwcoManish Goregaokar-31/+26
expected_found `&T` -> `T`
2020-07-05Rollup merge of #74000 - lcnr:lazy_normalisation_consts, r=varkorManish Goregaokar-1/+1
add `lazy_normalization_consts` feature gate In #71973 I underestimated the amount of code which is influenced by lazy normalization of consts and decided against having a separate feature flag for this. Looking a bit more into this, the following issues are already working with lazy norm in its current state #47814 #57739 #73980 I therefore think it is worth it to enable lazy norm separately. Note that `#![feature(const_generics)]` still automatically activates this feature, so using `#![feature(const_generics, lazy_normalization_consts)]` is redundant. r? @varkor @nikomatsakis
2020-07-05Rollup merge of #73871 - da-x:private-types-2018-no-extern, r=petrochenkovManish Goregaokar-17/+18
Fix try_print_visible_def_path for Rust 2018 The recursive check of `try_print_visible_def_path` did not properly handle the Rust 2018 case of crate-paths without 'extern crate'. Instead, it returned a "not found" via (false, self). This fixes #56175.
2020-07-05Use for<'tcx> fn pointers in Providers, instead of having Providers<'tcx>.Eduard-Mihai Burtescu-18/+21
2020-07-05Replace early-bound normalization hack with per-query key/value type aliases.Eduard-Mihai Burtescu-2/+21
2020-07-05Avoid deconstructing pointer for hashingMark Rousskov-2/+3
2020-07-05Shrink ParamEnv to 16 bytesMark Rousskov-16/+114
2020-07-05expected found `&T` -> `T`Bastian Kauschke-31/+26
2020-07-04add `lazy_normalization_consts` feature gateBastian Kauschke-1/+1
2020-07-03Rollup merge of #73949 - wesleywiser:simplify_try_fixes, r=oli-obkManish Goregaokar-0/+12
[mir-opt] Fix mis-optimization and other issues with the SimplifyArmIdentity pass This does not yet attempt re-enabling the pass, but it does resolve a number of issues with the pass. r? @oli-obk I believe this closes #73223.
2020-07-02Fix debuginfo so that it points to the correct localWesley Wiser-0/+12
2020-07-02Auto merge of #73751 - eddyb:no-empty-tables, r=nikomatsakisbors-42/+27
Remove `TypeckTables::empty(None)` and make hir_owner non-optional. Each commit before the last one removes uses of `TypeckTables::empty(None)`, replacing the empty tables with having `Option` around the `&'tcx TypeckTables<'tcx>` that HIR visitors kept track of. The last commit removes the concept of "empty `TypeckTables`" altogether, guaranteeing that every `TypeckTables` corresponds to a HIR body owner. r? @nikomatsakis
2020-07-02Remove `TypeckTables::empty(None)` and make hir_owner non-optional.Eduard-Mihai Burtescu-42/+27
2020-07-02Auto merge of #73954 - Manishearth:rollup-8qvh170, r=Manishearthbors-17/+55
Rollup of 10 pull requests Successful merges: - #73414 (Implement `slice_strip` feature) - #73564 (linker: Create GNU_EH_FRAME header by default when producing ELFs) - #73622 (Deny unsafe ops in unsafe fns in libcore) - #73684 (add spans to injected coverage counters, extract with CoverageData query) - #73812 (ast_pretty: Pass some token streams and trees by reference) - #73853 (Add newline to rustc MultiSpan docs) - #73883 (Compile rustdoc less often.) - #73885 (Fix wasm32 being broken due to a NodeJS version bump) - #73903 (Changes required for rustc/cargo to build for iOS targets) - #73938 (Optimise fast path of checked_ops with `unlikely`) Failed merges: r? @ghost
2020-07-02Rollup merge of #73684 - richkadel:llvm-coverage-map-gen-2, r=wesleywiserManish Goregaokar-17/+55
add spans to injected coverage counters, extract with CoverageData query This is the next iteration on the Rust Coverage implementation, and follows PR #73488 @tmandry @wesleywiser I came up with an approach for coverage spans, pushing them through the Call terminator as additional args so they can be extracted by the CoverageData query. I'm using an IndexVec to store them in CoverageData such that there can be only one per index (even if parts of the MIR get duplicated during optimization). If this approach works for you, I can quickly expand on this to build a separate IndexVec for counter expressions, using a separate call that will be ignored during code generation, but from which I can extract the counter expression values. Let me know your thoughts. Thanks! r? @tmandry Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation
2020-07-01Rollup merge of #73906 - JohnTitor:missing-bt, r=jonas-schievinkManish Goregaokar-1/+1
Add missing backtick in `ty_error_with_message`
2020-07-01Rollup merge of #73569 - Aaron1011:fix/macro-rules-group, r=petrochenkovManish Goregaokar-0/+1
Handle `macro_rules!` tokens consistently across crates When we serialize a `macro_rules!` macro, we used a 'lowered' `TokenStream` for its body, which has all `Nonterminal`s expanded in-place via `nt_to_tokenstream`. This matters when an 'outer' `macro_rules!` macro expands to an 'inner' `macro_rules!` macro - the inner macro may use tokens captured from the 'outer' macro in its definition. This means that invoking a foreign `macro_rules!` macro may use a different body `TokenStream` than when the same `macro_rules!` macro is invoked in the same crate. This difference is observable by proc-macros invoked by a `macro_rules!` macro - a `None`-delimited group will be seen in the same-crate case (inserted when convering `Nonterminal`s to the `proc_macro` crate's structs), but no `None`-delimited group in the cross-crate case. To fix this inconsistency, we now insert `None`-delimited groups when 'lowering' a `Nonterminal` `macro_rules!` body, just as we do in `proc_macro_server`. Additionally, we no longer print extra spaces for `None`-delimited groups - as far as pretty-printing is concerned, they don't exist (only their contents do). This ensures that `Display` output of a `TokenStream` does not depend on which crate a `macro_rules!` macro was invoked from. This PR is necessary in order to patch the `solana-genesis-programs` for the upcoming hygiene serialization breakage (https://github.com/rust-lang/rust/pull/72121#issuecomment-646924847). The `solana-genesis-programs` crate will need to use a proc macro to re-span certain tokens in a nested `macro_rules!`, which requires us to consistently use a `None`-delimited group. See `src/test/ui/proc-macro/nested-macro-rules.rs` for an example of the kind of nested `macro_rules!` affected by this crate.