| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #67686 (Simplify NodeHeader by avoiding slices in BTreeMaps with shared roots)
- #68140 (Implement `?const` opt-out for trait bounds)
- #68313 (Options IP_MULTICAST_TTL and IP_MULTICAST_LOOP are 1 byte on BSD)
- #68328 (Actually pass target LLVM args to LLVM)
- #68399 (check_match: misc unifications and ICE fixes)
- #68415 (tidy: fix most clippy warnings)
- #68416 (lowering: cleanup some hofs)
Failed merges:
r? @ghost
|
|
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
|
|
A single framework for gen-kill and generic dataflow problems
This is the prototype implementation discussed in rust-lang/compiler-team#202. You can read a high-level description of it in [the proposal](https://hackmd.io/@39Qr_z9cQhasi25sGjmFnA/Skvd9rztS) for that design meeting. This would eventually supersede the existing `BitDenotation` interface.
r? @ghost
cc @rust-lang/compiler (esp. @eddyb and @pnkfelix)
|
|
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
|
|
|
|
It's confusing because it conflicts with ty::Const and just isn't
generally useful.
|
|
|
|
Turn off const propagation of ref taking
Fixes #67529
Fixes #67640
Fixes #67641
Fixes #67862
r? @oli-obk
|
|
const eval
|
|
Co-Authored-By: Oliver Scherer <github35764891676564198441@oli-obk.de>
|
|
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.
|
|
Promoteds can contain raw pointers, but these must still only point to immutable allocations
fixes #67601
r? @RalfJung
cc @wesleywiser in order to not change behaviour in this PR, const prop uses the constant rules for interning, but at least there's an explicit mode for it now that we can think about this in the future
|
|
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.
|
|
immutable allocations
|
|
|
|
|
|
|
|
|
|
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.
|
|
Fixes #67529
Fixes #67640
Fixes #67641
Fixes #67862
|
|
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
|
|
|
|
Move more of `rustc::lint` into `rustc_lint`
Based on https://github.com/rust-lang/rust/pull/67806.
Here we try to consolidate more of the linting infra into `rustc::lint`. Some high-level notes:
- We now store an `Lrc<dyn Any + Send + Sync>` as opposed to `Lrc<LintStore>` in the `GlobalCtxt`. This enables us to avoid referring to the type, breaking a cyclic dependency, and so we can move things from `rustc::lint` to `rustc_lint`.
- `in_derive_expansion` is, and needs to, be moved as a method on `Span`.
- We reduce the number of ways on `tcx` to emit a lint so that the developer UX is more streamlined.
- `LintLevelsBuilder` is moved to `rustc_lint::levels`, leaving behind `LintLevelMap/Set` in a purified form due to current constraints (hopefully fixable in the future after https://github.com/rust-lang/rust/pull/68133).
- `struct_lint_level` is moved to `rustc::lint` due to current dependency constraints.
- `rustc::lint::context` is moved to `rustc_lint::context`.
- The visitors in `rustc::lint` are moved to `rustc_lint::passes`.
|
|
Promote references to constants instead of statics
r? @oli-obk
|
|
Don't require `allow_internal_unstable` unless `staged_api` is enabled.
#63770 changed `qualify_min_const_fn` to require `allow_internal_unstable` for *all* crates that used an unstable feature, regardless of whether `staged_api` was enabled or the `fn` that used that feature was stably const. In practice, this meant that every crate in the ecosystem that wanted to use nightly features added `#![feature(const_fn)]`, which skips `qualify_min_const_fn` entirely.
After this PR, crates that do not have `#![feature(staged_api)]` will only need to enable the feature they are interested in. For example, `#![feature(const_if_match)]` will be enough to enable `if` and `match` in constants. Crates with `staged_api` (e.g., `libstd`) require `#[allow_internal_unstable]` to be added to a function if it uses nightly features unless that function is also marked `#[rustc_const_unstable]`. This prevents proliferation of `#[allow_internal_unstable]` into functions that are not callable in a `const` context on stable.
r? @oli-obk (author of #63770)
cc @Centril
|
|
|
|
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
|
|
Clarify suggestion for E0013
Fixes https://github.com/rust-lang/rust/issues/68038.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Reduce special treatment for zsts
addresses https://github.com/rust-lang/rust/pull/67467#discussion_r360650846
cc @RalfJung
|
|
Delay bug to prevent ICE in MIR borrowck
Fixes #67947
r? @matthewjasper
|
|
Move `intravisit` => `rustc_hir` + misc cleanup
Working towards https://github.com/rust-lang/rust/issues/65031.
This should eventually enable getting rid of rustc as a dependency in various passes (e.g. lints).
cc https://github.com/rust-lang/rust/pull/67806 (this also facilitates liberating lints from tcx)
cc https://github.com/rust-lang/rust/pull/67922 (some other dep reductions)
r? @Zoxc
|