| Age | Commit message (Collapse) | Author | Lines |
|
This replaces the need for the `description` and `details` symbols in
`UnsafetyViolation`, which are static. As a result some
`Symbol::as_str()` calls are no longer necessary, which is nice.
|
|
Don't panic if the lhs of a div by zero is not statically known
Fixes #73993 for real this time
r? @wesleywiser
|
|
|
|
Support const args in type dependent paths (Take 2)
once more, except it is sound this time :smiling_face_with_three_hearts: previously #71154
-----
```rust
#![feature(const_generics)]
struct A;
impl A {
fn foo<const N: usize>(&self) -> usize { N }
}
struct B;
impl B {
fn foo<const N: usize>(&self) -> usize { 42 }
}
fn main() {
let a = A;
a.foo::<7>();
}
```
When calling `type_of` for generic const arguments, we now use the `TypeckTables` of the surrounding body to get the expected type.
This alone causes cycle errors though, as we now have `typeck_tables_of(main)` -> `...` ->
`type_of(main_ANON0 := 7)` -> `typeck_tables_of(main)` :zap: (see https://github.com/rust-lang/rust/issues/68400#issuecomment-611760290)
To prevent this we must not call `type_of(const_arg)` during `typeck_tables_of`. This is achieved by
calling `type_of(param_def_id)` instead.
We have to somehow remember the `DefId` of the param through all of typeck, which is done using the
struct `ty::WithOptConstParam<DefId>`, which replaces `DefId` where needed and contains an `Option<DefId>` to
be able to store the const parameter in case it exists.
Queries which are currently cached on disk are split into two variants: `query_name`(cached) and `query_name_(of|for)_const_arg`(not cached), with `query_name_of_const_arg` taking a pair `(did, param_did): (LocalDefId, DefId)`.
For some queries a method `query_name_of_opt_const_arg` is added to `TyCtxt` which takes a `ty::WithOptConstParam` and either calls `query_name` or `query_name_of_const_arg` depending on the value of `const_param_did`.
r? @eddyb @varkor
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
Note that the output of `unpretty-debug.stdout` has changed. In that
test the hash values are normalized from a symbol numbers to small
numbers like "0#0" and "0#1". The increase in the number of static
symbols must have caused the original numbers to contain more digits,
resulting in different pretty-printing prior to normalization.
|
|
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
|
|
|
|
Avoid "whitelist"
Other terms are more inclusive and precise.
|
|
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
|
|
Other terms are more inclusive and precise.
|
|
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
|
|
Also adds some debug assertions to prevent API consumers from visiting
those basic blocks by accident.
|
|
|
|
Miri value validation: fix handling of uninit memory
Fixes https://github.com/rust-lang/miri/issues/1456
Fixes https://github.com/rust-lang/miri/issues/1467
r? @oli-obk
|
|
Rollup of 14 pull requests
Successful merges:
- #70563 ([rustdoc] Page hash handling)
- #73856 (Edit librustc_lexer top-level docs)
- #73870 (typeck: adding type information to projection)
- #73953 (Audit hidden/short code suggestions)
- #73962 (libstd/net/tcp.rs: #![deny(unsafe_op_in_unsafe_fn)])
- #73969 (mir: mark mir construction temporaries as internal)
- #73974 (Move A|Rc::as_ptr from feature(weak_into_raw) to feature(rc_as_ptr))
- #74067 (rustdoc: Restore underline text decoration on hover for FQN in header)
- #74074 (Fix the return type of Windows' `OpenOptionsExt::security_qos_flags`.)
- #74078 (Always resolve type@primitive as a primitive, not a module)
- #74089 (Add rust-analyzer to the build manifest)
- #74090 (Remove unused RUSTC_DEBUG_ASSERTIONS)
- #74102 (Fix const prop ICE)
- #74112 (Expand abbreviation in core::ffi description)
Failed merges:
r? @ghost
|
|
Fix const prop ICE
we used to erase the local just before we tried to read it for diagnostics
fixes #73993
r? @wesleywiser
|
|
Shrink ParamEnv to 16 bytes
r? @nnethercote
x.py check passes but I haven't tried running perf or tests
|
|
Convert more `DefId`s to `LocalDefId`s
|
|
|
|
Handle inactive enum variants in `MaybeUninitializedPlaces`
Resolves the first part of #69715.
This is the equivalent of #68528 but for `MaybeUninitializedPlaces`. Because we now notify drop elaboration that inactive enum variants might be uninitialized, some drops get marked as ["open" that were previously "static"](https://github.com/rust-lang/rust/blob/e0e5d82e1677c82d209b214bbfc2cc5705c2336a/src/librustc_mir/transform/elaborate_drops.rs#L191). Unlike in #69715, this isn't strictly better: An "open" drop expands to more MIR than a simple call to the drop shim. However, because drop elaboration considers each field of an "open" drop separately, it can sometimes eliminate unnecessary drops of moved-from or unit-like enum variants. This is the case for `Option::unwrap`, which is reflected in the `mir-opt` test.
cc @eddyb
r? @oli-obk
|
|
|
|
|
|
|
|
|
|
we used to erase the local just before we tried to read it for diagnostics
|
|
Co-authored-by: varkor <github@varkor.com>
|
|
|
|
|
|
[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.
|
|
Use exhaustive match in const_prop.rs
Addresses a comment left by @RalfJung on #73613
r? @RalfJung
|
|
|
|
|
|
If temporaries are used beyond just the temporary chain, then we can't
optimize out the reads and writes.
|
|
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
|
|
Use an 'approximate' universal upper bound when reporting region errors
Fixes #67765
When reporting errors during MIR region inference, we sometimes use
`universal_upper_bound` to obtain a named universal region that we
can display to the user. However, this is not always possible - in a
case like `fn foo<'a, 'b>() { .. }`, the only upper bound for a region
containing `'a` and `'b` is `'static`. When displaying diagnostics, it's
usually better to display *some* named region (even if there are
multiple involved) rather than fall back to a generic error involving
`'static`.
This commit adds a new `approx_universal_upper_bound` method, which
uses the lowest-numbered universal region if the only alternative is to
return `'static`.
|
|
Make `likely` and `unlikely` const, gated by feature `const_unlikely`
This PR also contains a fix to allow `#[allow_internal_unstable]` to work properly with `#[rustc_const_unstable]`.
cc @RalfJung @nagisa
r? @oli-obk
|
|
|