about summary refs log tree commit diff
path: root/src/librustc_middle
AgeCommit message (Collapse)AuthorLines
2020-05-01remove AllocId generalization of PointerRalf Jung-16/+12
2020-05-01use hex for invalid bool and char (consistently with validation)Ralf Jung-2/+6
2020-05-01rename InvalidIntPtrUsageRalf Jung-40/+44
2020-05-01InterpError printing really is more Display than DebugRalf Jung-30/+27
also tweak InvalidDiscriminant message
2020-05-01tweak InvalidIntPointerUsage messageRalf Jung-2/+2
2020-05-01Auto merge of #70674 - cjgillot:query-arena-all, r=matthewjasperbors-132/+99
Have the per-query caches store the results on arenas This PR leverages the cache for each query to serve as storage area for the query results. It introduces a new cache `ArenaCache`, which moves the result to an arena, and only stores the reference in the hash map. This allows to remove a sizeable part of the usage of the global `TyCtxt` arena. I only migrated queries that already used arenas before.
2020-04-30Rollup merge of #71590 - RalfJung:mir-dump-pointers, r=oli-obkTyler Mandry-10/+34
MIR dump: print pointers consistently with Miri output This makes MIR allocation dump pointer printing consistent with Miri output: both use hexadecimal offsets with a `0x` prefix. To save some space, MIR dump replaces the `alloc` prefix by `a` when necessary. I also made AllocId/Pointer printing more consistent in their Debug/Display handling, and adjusted Display printing for Scalar a bit to avoid using decimal printing when we do not know the sign with which to interpret the value (IMO using decimal then is misleading).
2020-04-30Rollup merge of #71465 - oli-obk:is_thread_local_cleanup, r=matthewjasperTyler Mandry-4/+10
Add a convenience method on `TyCtxt` for checking for thread locals This PR extracts the cleanup part of #71192 r? @bjorn3
2020-04-30Rollup merge of #71449 - ecstatic-morse:free-region-cleanup, r=Mark-SimulacrumDylan DPC-179/+0
Move `{Free,}RegionRelations` and `FreeRegionMap` to `rustc_infer` ...and out of `rustc_middle`. This is to further #65031, albeit in a very minor way r? @Mark-Simulacrum
2020-04-30Miri: port error backtraces to std::backtraceRalf Jung-12/+10
2020-04-30handle ByRef in relateBastian Kauschke-2/+34
2020-04-30Address review commentsOliver Scherer-4/+2
2020-04-30Highlight an error that can only happen in CTFEOliver Scherer-1/+1
2020-04-30Add a convenience function for testing whether a static is `#[thread_local]`Oliver Scherer-0/+6
2020-04-30Separate miri/ctfe unsupported operationsOliver Scherer-0/+2
2020-04-29Auto merge of #67343 - ecstatic-morse:qualif-structural-match, r=pnkfelixbors-0/+1
Const qualification for `StructuralEq` Furthers #62411. Resolves #62614. The goal of this PR is to implement the logic in #67088 on the MIR instead of the HIR. It uses the `Qualif` trait to track `StructuralPartialEq`/`StructuralEq` in the final value of a `const`. Then, if we encounter a constant during HAIR lowering whose value may not be structurally matchable, we emit the `indirect_structural_match` lint. This PR contains all the tests present in #67088 and emits the proper warnings for the corner cases. This PR does not handle #65466, which would require that we be [more aggressive](https://github.com/rust-lang/rust/blob/42abbd8878d3b67238f3611b0587c704ba94f39c/src/librustc_mir_build/hair/pattern/const_to_pat.rs#L126-L130) when checking matched types for `PartialEq`. I think that should be done separately. Because this works on MIR and uses dataflow, this PR should accept more cases than #67088. Notably, the qualifs in the final value of a const are encoded cross-crate, so matching on a constant whose value is defined in another crate to be `Option::<TyWithCustomEqImpl>::None` should work. Additionally, if a `const` has branching/looping, we will only emit the warning if any possible control flow path could result in a type with a custom `PartialEq` impl ending up as the final value of a `const`. I'm not sure how #67088 handled this. AFAIK, it's not settled that these are the semantics we actually want: it's just how the `Qualif` framework happens to work. If the cross-crate part is undesirable, it would be quite easy to change the result of `mir_const_qualif().custom_eq` to `true` before encoding it in the crate metadata. This way, other crates would have to assume that all publicly exported constants may not be safe for matching. r? @pnkfelix cc @eddyb
2020-04-29Rollup merge of #71217 - estebank:tail-borrow-sugg, r=pnkfelixDylan DPC-0/+3
Suggest `;` or assignment to drop borrows in tail exprs Address the diagnostics part of #70844. ``` error[E0597]: `counter` does not live long enough --> $DIR/issue-54556-niconii.rs:22:20 | LL | if let Ok(_) = counter.lock() { } | ^^^^^^^------- | | | borrowed value does not live long enough | a temporary with access to the borrow is created here ... ... LL | } | - | | | `counter` dropped here while still borrowed | ... and the borrow might be used here, when that temporary is dropped and runs the destructor for type `std::result::Result<MutexGuard<'_>, ()>` | help: consider adding semicolon after the expression so its temporaries are dropped sooner, before the local variables declared by the block are dropped | LL | if let Ok(_) = counter.lock() { }; | ^ ```
2020-04-28Suggest `;` or assignment to drop borrows in tail exprsEsteban Küber-0/+3
Address the diagnostics part of #70844. ``` error[E0597]: `counter` does not live long enough --> $DIR/issue-54556-niconii.rs:22:20 | LL | if let Ok(_) = counter.lock() { } | ^^^^^^^------- | | | borrowed value does not live long enough | a temporary with access to the borrow is created here ... ... LL | } | - | | | `counter` dropped here while still borrowed | ... and the borrow might be used here, when that temporary is dropped and runs the destructor for type `std::result::Result<MutexGuard<'_>, ()>` | help: consider adding semicolon after the expression so its temporaries are dropped sooner, before the local variables declared by the block are dropped | LL | if let Ok(_) = counter.lock() { }; | ^ ```
2020-04-28Add `CustomEq` qualifDylan MacKenzie-0/+1
2020-04-28Move a few queries to using an arena.Camille GILLOT-9/+13
2020-04-28Fix incremental compilation.Camille GILLOT-4/+6
2020-04-28Use the query system to allocate.Camille GILLOT-121/+73
2020-04-28Introduce ArenaStorage.Camille GILLOT-2/+3
2020-04-28Allow the QueryCache to specify storage.Camille GILLOT-3/+11
2020-04-27Accept `LocalDefId` as key for `check_impl_item_well_formed` querymarmeladema-1/+3
2020-04-27Accept `LocalDefId` as key for `check_trait_item_well_formed` querymarmeladema-1/+3
2020-04-27Accept `LocalDefId` as key for `check_item_well_formed` querymarmeladema-1/+3
2020-04-27Change return type of `entry_fn` query to return a `LocalDefId`marmeladema-3/+3
2020-04-27Accept `LocalDefId` as key for `check_mod_privacy` querymarmeladema-2/+2
2020-04-27Accept `LocalDefId` as key for `lint_mod` querymarmeladema-2/+2
2020-04-27Accept `LocalDefId` as key for `mir_validated` querymarmeladema-1/+2
2020-04-27Accept `LocalDefId` as key for `mir_borrowck` querymarmeladema-5/+4
2020-04-27Return a `FxHashSet<LocalDefId>` from `mir_keys` querymarmeladema-2/+3
2020-04-27Accept `LocalDefId` as keyt for `names_imported_by_glob_use`marmeladema-10/+10
and `maybe_unused_trait_import` queries
2020-04-27Use `LocalDefId` for `type_param_predicates` querymarmeladema-2/+13
2020-04-27Use `LocalDefId` in `mir_built` querymarmeladema-1/+1
2020-04-27Use `LocalDefId` in `unsafety_check_result` querymarmeladema-3/+3
2020-04-27Use `LocalDefId` in `typeck_tables_of` and `used_trait_imports` queriesmarmeladema-8/+10
2020-04-27keep 'pointer' terminology aroundRalf Jung-1/+4
2020-04-27Auto merge of #71268 - estebank:devectorize, r=eddybbors-7/+5
Remove some `Vec` allocations to improve performance This claws back most of the performance lost in https://github.com/rust-lang/rust/pull/69745. r? @eddyb
2020-04-26Rollup merge of #71569 - samrat:miri-ub-on-size-mismatch, r=RalfJungDylan DPC-1/+16
[miri] Throw UB if target size and data size don't match Issue: https://github.com/rust-lang/miri/issues/1355 If an extern C function is defined as ``` extern "C" { fn malloc(size: u32) -> *mut std::ffi::c_void; } ``` on a 64-bit machine(ie. pointer sizes don't match), return undefined behaviour from Miri when [converting the argument into machine_usize](https://github.com/rust-lang/miri/blob/master/src/shims/foreign_items.rs#L200)
2020-04-26fmtRalf Jung-5/+1
2020-04-26organize Debug/Display impls a bit more; avoid sign-ignorant decimal displayRalf Jung-20/+23
2020-04-26Adjust styleRalf Jung-1/+1
2020-04-26print pointers more compactly when they are too bigRalf Jung-10/+32
2020-04-26Rename ArgumentSizeMismatch to ScalarSizeMismatchSamrat Man Singh-5/+5
2020-04-26[miri] Throw UB if target size and data size don't matchSamrat Man Singh-1/+16
If an extern C function is defined as ``` extern "C" { fn malloc(size: u32) -> *mut std::ffi::c_void; } ``` on a 64-bit machine(ie. pointer sizes don't match), throw an undefined behaviour.
2020-04-26Rollup merge of #71392 - ecstatic-morse:body-predecessor-cache-arc, ↵Dylan DPC-31/+31
r=nikomatsakis Don't hold the predecessor cache lock longer than necessary #71044 returns a `LockGuard` with the predecessor cache to callers of `Body::predecessors`. As a result, the lock around the predecessor cache could be held for an arbitrarily long time. This PR uses reference counting for ownership of the predecessor cache, meaning the lock is only ever held within `PredecessorCache::compute`. Checking this API for potential sources of deadlock is much easier now, since we no longer have to consider its consumers, only its internals. This required removing `predecessors_for`, since there is no equivalent to `LockGuard::map` for `Arc` and `Rc`. I believe this could be emulated with `owning_ref::{Arc,Rc}Ref`, but I don't think it's necessary. Also, we continue to return an opaque type from `Body::predecessors` with the lifetime of the `Body`, not `'static`. This depends on #71044. Only the last two commits are new. r? @nikomatsakis
2020-04-26Rollup merge of #70043 - mark-i-m:def-kind-more, r=eddybDylan DPC-49/+47
Add all remaining `DefKind`s. r? @eddyb or @Centril ~~I'm not sure if this is what you were thinking of. There are also a few places where I'm not sure what the correct choice is because I don't fully understand the meaning of some variants.~~ ~~In general, it feels a bit odd to add some of these as `DefKind`s (e.g. `Arm`) because they don't feel like definitions. Are there things that it makes sense not to add?~~
2020-04-24Replace filter_map().next() calls with find_map()Josh Stone-10/+6
These are semantically the same, but `find_map()` is more concise.