| Age | Commit message (Collapse) | Author | Lines |
|
Remove the `overlapping_marker_traits` feature
See #29864
This has been replaced by `#[feature(marker_trait_attr)]`
A few notes:
* Due to PR #68057 not yet being in the bootstrap compiler, it's
necessary to continue using `#![feature(overlapping_marker_traits)]`
under `#[cfg(bootstrap)]` to work around type inference issues.
* I've updated tests that used `overlapping_marker_traits` to now use
`marker_trait_attr` where applicable
The test `src/test/ui/overlap-marker-trait.rs` doesn't make any sense
now that `overlapping_marker_traits`, so I removed it.
The test `src/test/ui/traits/overlap-permitted-for-marker-traits-neg.rs`
now fails, since it's no longer possible to have multiple overlapping
negative impls of `Send`. I believe that this is the behavior we want
(assuming that `Send` is not going to become a `#[marker]` trait, so I
renamed the test to `overlap-permitted-for-marker-traits-neg`
|
|
fix couple of perf related clippy warnings
librustc: don't clone a type that is copy
librustc_incremental: use faster vector initialization
librustc_typeck: don't clone a type that is copy
librustdoc: don't create a vector where a slice will do
|
|
remove redundant imports (clippy::single_component_path_imports)
|
|
See #29864
This has been replaced by `#[feature(marker_trait_attr)]`
A few notes:
* Due to PR #68057 not yet being in the bootstrap compiler, it's
necessary to continue using `#![feature(overlapping_marker_traits)]`
under `#[cfg(bootstrap)]` to work around type inference issues.
* I've updated tests that used `overlapping_marker_traits` to now use
`marker_trait_attr` where applicable
The test `src/test/ui/overlap-marker-trait.rs` doesn't make any sense
now that `overlapping_marker_traits`, so I removed it.
The test `src/test/ui/traits/overlap-permitted-for-marker-traits-neg.rs`
now fails, since it's no longer possible to have multiple overlapping
negative impls of `Send`. I believe that this is the behavior we want
(assuming that `Send` is not going to become a `#[marker]` trait, so I
renamed the test to `overlap-permitted-for-marker-traits-neg`
|
|
|
|
librustc: don't clone a type that is copy
librustc_incremental: use faster vector initialization
librustc_typeck: don't clone a type that is copy
librustdoc: don't create a vector where a slice will do
|
|
|
|
|
|
* Handle arrays with const-generic lengths
* Use closure for repeated code.
|
|
* Handle cycles in `needs_drop` correctly
* Normalize types when computing `needs_drop`
* Move queries from rustc to rustc_ty
|
|
|
|
|
|
|
|
...and unify it with `()` for now
|
|
|
|
|
|
2. invert rustc_session & syntax deps
3. drop rustc_session dep in rustc_hir
|
|
For now, this is all the crate contains, but more
attribute logic & types will be moved there over time.
|
|
|
|
Don't use spaces before type ascription like colons
Split out of #67133 to make that PR simpler
r? @eddyb
|
|
perf: Avoid creating a SmallVec if nothing changes during a fold
Not sure if this helps but in theory it should be less work than what
the current micro optimization does for `ty::Predicate` lists.
(It would explain the overhead I am seeing from `perf`.)
|
|
|
|
Print constants in `type_name` for const generics
Fixes https://github.com/rust-lang/rust/issues/65372.
r? @oli-obk as there may have been a deliberate decision not to in https://github.com/rust-lang/rust/commit/5b9848912a85e28d000602fc2e81bad9c2f2a981#diff-4ed1a72c0bfdf17be769ed520932cd02R80.
|
|
|
|
Also share drop-glue when compiling with -Zshare-generics (i.e. at opt-level=0)
This PR adds drop-glue to the set of monomorphizations that can be shared across crates via `-Zshare-generics`.
This version of the PR might have detrimental effects on performance as it makes lots of stuff dependent on a single query results (`upstream_monomorphizations_for(def_id_of_drop_in_place)`). That should be fixable but let's do a perf run first.
Potentially fixes issue https://github.com/rust-lang/rust/issues/64140. (cc @alexcrichton)
The changes here are related to @matthewjasper's https://github.com/rust-lang/rust/pull/67332 but should be mostly orthogonal.
r? @ghost
|
|
This reduces the amount of invalidated data when new types are
add to upstream crates.
|
|
names.
|
|
|
|
Implement `?const` opt-out for trait bounds
For now, such bounds are treated exactly the same as unprefixed ones in all contexts. [RFC 2632](https://github.com/rust-lang/rfcs/pull/2632) does not specify whether such bounds are forbidden outside of `const` contexts, so they are allowed at the moment.
Prior to this PR, the constness of a trait bound/impl was stored in `TraitRef`. Now, the constness of an `impl` is stored in `ast::ItemKind::Impl` and the constness of a bound in `ast::TraitBoundModifer`. Additionally, constness of trait bounds is now stored in an additional field of `ty::Predicate::Trait`, and the combination of the constness of the item along with any `TraitBoundModifier` determines the constness of the bound in accordance with the RFC. Encoding the constness of impls at the `ty` level is left for a later PR.
After a discussion in \#wg-grammar on Discord, it was decided that the grammar should not encode the mutual exclusivity of trait bound modifiers. The grammar for trait bound modifiers remains `[?const] [?]`. To encode this, I add a dummy variant to `ast::TraitBoundModifier` that is used when the syntax `?const ?` appears. This variant causes an error in AST validation and disappears during HIR lowering.
cc #67794
r? @oli-obk
|
|
Fix #[track_caller] and function pointers
Starting with failing tests, fix the miscompilation and ICE caused by `ReifyShim` bug.
Fixes #68178.
|
|
Filter and test predicates using `normalize_and_test_predicates` for const-prop
Fixes #68264
Previously, I attempted to use
`substitute_normalize_and_test_predicates` to detect unsatisfiable
bounds. Unfortunately, since const-prop runs in a generic environment
(we don't have any of the function's generic parameters substituted),
this could lead to cycle errors when attempting to normalize predicates.
This check is replaced with a more precise check. We now only call
`normalize_and_test_predicates` on predicates that have the possibility
of being proved unsatisfiable - that is, predicates that don't depend
on anything local to the function (e.g. generic parameters). This
ensures that we don't hit cycle errors when we normalize said
predicates, while still ensuring that we detect unsatisfiable
predicates.
I haven't been able to come up with a minimization of the Diesel issue - however, I've verified that it compiles successfully.
|
|
|
|
|
|
Remove `rustc_error_codes` deps except in `rustc_driver`
Remove dependencies on `rustc_error_codes` in all crates except for `rustc_driver`.
This has some benefits:
1. Adding a new error code when hacking on the compiler only requires rebuilding at most `rustc_error_codes`, `rustc_driver`, and the reflexive & transitive closure of the crate where the new error code is being added and its reverse dependencies. This improves time-to-UI-tests (TTUT).
2. Adding an error description to an error code only requires rebuilding `rustc_error_codes` and `rustc_driver`. This should substantially improve TTUT.
r? @petrochenkov
cc @rust-lang/wg-diagnostics
|
|
Don't discard marker trait impls when inference variables are present
Fixes #61651
Previously, we would unconditionally discard impl candidates for marker
traits during trait selection. However, if the predicate had inference
variables, this could have the effect of constrainting inference
variables (due to a successful trait selection) when we would have
otherwise failed due to mutliple applicable impls,
This commit prevents marker trait impls from being discarded while the
obligation predicate has any inference variables, ensuring that
discarding impls will never cause us to incorrectly constraint inference
variables.
|
|
|
|
|
|
Implement Lift using interners instead of in_arena
r? @eddyb
cc @cjgillot
|
|
|
|
|
|
Move some queries from rustc::ty to librustc_ty.
cc #65031
|
|
Suggest to shorten temporary lifetime during method call inside generator
Closes https://github.com/rust-lang/rust/issues/67376

r? @estebank
cc @tmandry @nikomatsakis
|
|
r=matthewjasper,oli-obk
Don't run const propagation on items with inconsistent bounds
Fixes #67696
Using `#![feature(trivial_bounds)]`, it's possible to write functions
with unsatisfiable 'where' clauses, making them uncallable. However, the
user can act as if these 'where' clauses are true inside the body of the
function, leading to code that would normally be impossible to write.
Since const propgation can run even without any user-written calls to a
function, we need to explcitly check for these uncallable functions.
|
|
|
|
|
|
|
|
unevaluated consts
which requires a lot of unnecessary work to evaluate them further down the line.
|
|
|
|
|
|
Split MIR building into its own crate
This moves `rustc_mir::{build, hair, lints}` to `rustc_mir_build`.
The new crate only has a `provide` function as it's public API.
Based on #67898
cc @Centril @rust-lang/compiler
r? @oli-obk
|