| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fix ICEs with `@ ..` binding
This reverts #74557 and introduces an alternative fix while ensuring that #74954 is not broken.
The diagnostics are verbose though, it fixes three related issues.
cc #74954, #74539, and #74702
|
|
Deduplicate `::` -> `:` typo errors
Deduplicate errors caused by the same type ascription typo, including
ones suggested during parsing that would get reported again during
resolve. Fix #70382.
|
|
report kind of deprecated item in message
This is important for fields, which are incorrectly referred to as
"items".
|
|
Rename HAIR to THIR (Typed HIR).
r? @nikomatsakis
Originally suggested by @eddyb
|
|
[mir] Special treatment for dereferencing a borrow to a static definition
Fix #70584.
As suggested by @oli-obk in this [comment](https://github.com/rust-lang/rust/issues/70584#issuecomment-626009260), one can chase the definition of the local variable being de-referenced and check if it is a true static variable. If that is the case, `validate_place` will admit the promotion.
This is my first time to contribute to `rustc`, and I have two questions.
1. A generalization to some extent is applied to decide if the promotion is possible in the static context. In case that there are more projection operations preceding the de-referencing, `validate_place` recursively decent into inner projection operations. I have put thoughts into its correctness but I am not totally sure about it.
2. I have a hard time to find a good place for the test case. This patch has to do with MIR, but this test case would look out of place compared to other tests in `src/test/ui/mir` or `src/test/ui/borrowck` because it does not generate errors while others do. It is tentatively placed in `src/test/ui/statics` for now.
Thank you for any comments and suggestions!
|
|
davidtwco:issue-74636-polymorphized-closures-inherited-params, r=oli-obk
mir: add `used_generic_parameters_needs_subst`
Fixes #74636.
This PR adds a `used_generic_parameters_needs_subst` helper function which checks whether a type needs substitution, but only for parameters that the `unused_generic_params` query considers used. This is used in the MIR interpreter to make the check for some pointer casts and for reflection intrinsics more precise.
I've opened this as a draft PR because this might not be the approach we want to fix this issue and we have to decide what to do about the reflection case.
r? @eddyb
cc @lcnr @wesleywiser
|
|
Fix Const-Generic Cycle ICE #74199
This PR intends to fix the bug in Issue #74199 by following the suggestion provided of ignoring the error that causes the ICE.
This does not fix the underlying cycle detection issue, but fixes the ICE.
Also adds a test to check that it doesn't causes an ICE but returns a valid error for now.
r? @lcnr
Edit: Also it's funny how this PR number is an anagram of the issue number
|
|
|
|
|
|
* Deduplicate type ascription LHS errors
* Remove duplicated `:` -> `::` suggestion from parse error
* Tweak wording to be more accurate
* Modify `current_type_ascription` to reduce span wrangling
* remove now unnecessary match arm
* Add run-rustfix to appropriate tests
|
|
This commit adds a `ensure_monomorphic_enough` utility function which
checks whether a type needs substitution, but only for parameters
that the `unused_generic_params` query considers used.
`ensure_monomorphic_enough` is then used throughout interpret where
`needs_subst` checks previously existed (in particular, for some
pointer casts and for reflection intrinsics more precise).
Signed-off-by: David Wood <david@davidtw.co>
|
|
|
|
Make `Option::unwrap` unstably const
This is lumped into the `const_option` feature gate (#67441), which enables a potpourri of `Option` methods.
cc @rust-lang/wg-const-eval
r? @oli-obk
|
|
|
|
This reverts commit f5e5eb6f46ef2cf0dd45dba4f975305509334fc6.
|
|
|
|
Improve diagnostics when constant pattern is too generic
This PR is a follow-up to PR #74538 and issue #73976
When constants queries Layout, TypeId or type_name of a generic parameter, instead of emitting `could not evaluate constant pattern`, we will instead emit a more detailed message `constant pattern depends on a generic parameter`.
|
|
|
|
Fix incorrect clashing_extern_declarations warnings.
Fixes #73735, fixes #73872.
Fix clashing_extern_declarations warning for `#[repr(transparent)]` structs and safely-FFI-convertible enums, and not warning for clashes of struct members of different types, but the same size.
r? @nagisa
|
|
|
|
Make `mem::size_of_val` and `mem::align_of_val` unstably const
Implements #46571 but does not stabilize it. I wanted this while working on something today.
The only reason not to immediately stabilize are concerns around [custom DSTs](https://github.com/rust-lang/rust/issues/46571#issuecomment-387669352). That proposal has made zero progress in the last two years and const eval is rich enough to support pretty much any user-defined `len` function as long as nightly features are allowed (`raw_ptr_deref`).
Currently, this raises a `const_err` lint when passed an `extern type`.
r? @oli-obk
cc @rust-lang/wg-const-eval
|
|
|
|
- Make `is_repr_nullable_ptr` freestanding again to avoid usage of
ImproperCTypesVisitor in ClashingExternDeclarations (and don't
accidentally revert the ParamEnv::reveal_all() fix from a week earlier)
- Revise match condition for 1 Adt, 1 primitive
- Generalise check for non-null type so that it would also work for
ranges which exclude any single value (all bits set, for example)
- Make is_repr_nullable_ptr return the representable type instead of
just a boolean, to avoid adding an additional, independent "source of
truth" about the FFI-compatibility of Option-like enums. Also, rename to
`repr_nullable_ptr`.
|
|
Co-authored-by: Teymour Aldridge <42674621+teymour-aldridge@users.noreply.github.com>
|
|
An example of an FFI-safe enum conversion is when converting
Option<NonZeroUsize> to usize. Because the Some value must be non-zero,
rustc can use 0 to represent the None variant, making this conversion is
safe. Furthermore, it can be relied on (and removing this optimisation
already would be a breaking change).
|
|
|
|
|
|
|
|
Make closures and generators a must use types
Warn about unused expressions with closure or generator type. This follows
existing precedence of must use annotations present on `FnOnce`, `FnMut`, `Fn`
traits, which already indirectly apply to closures in some cases, e.g.,:
```rust
fn f() -> impl FnOnce() {
|| {}
}
fn main() {
// an existing warning: unused implementer of `std::ops::FnOnce` that must be used:
f();
// a new warning: unused closure that must be used:
|| {};
}
```
Closes #74691.
|
|
Stabilize const_type_id feature
The tracking issue for `const_type_id` points to the ill-fated #41875. So I'm re-energizing `TypeId` shenanigans by opening this one up to see if there's anything blocking us from stabilizing the constification of type ids.
Will wait for CI before pinging teams/groups.
-----
This PR stabilizes the `const_type_id` feature, which allows `TypeId::of` (and the underlying unstable intrinsic) to be called in constant contexts.
There are some [sanity tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/consts/const-typeid-of-rpass.rs) that demonstrate its usage, but I’ve included some more below.
As a simple example, you could create a constant item that contains some type ids:
```rust
use std::any::TypeId;
const TYPE_IDS: [TypeId; 2] = [
TypeId::of::<u32>(),
TypeId::of::<i32>(),
];
assert_eq!(TypeId::of::<u32>(), TYPE_IDS[0]);
```
Type ids can also now appear in associated constants. You could create a trait that associates each type with its constant type id:
```rust
trait Any where Self: 'static {
const TYPE_ID: TypeId = TypeId::of::<Self>();
}
impl<T: 'static> Any for T { }
assert_eq!(TypeId::of::<usize>(), usize::TYPE_ID);
```
`TypeId::of` is generic, which we saw above in the way the generic `Self` argument was used. This has some implications for const evaluation. It means we can make trait impls evaluate differently depending on information that wasn't directly passed through the trait system. This violates the _parametricity_ property, which requires all instances of a generic function to behave the same way with respect to its generic parameters. That's not unique to `TypeId::of`, other generic const functions based on compiler intrinsics like `mem::align_of` can also violate parametricity. In practice Rust doesn't really have type parametricity anyway since it monomorphizes generics into concrete functions, so violating it using type ids isn’t new.
As an example of how impls can behave differently, you could combine constant type ids with the `const_if_match` feature to dispatch calls based on the type id of the generic `Self`, rather than based on information about `Self` that was threaded through trait bounds. It's like a rough-and-ready form of specialization:
```rust
#![feature(const_if_match)]
trait Specialized where Self: 'static {
// An associated constant that determines the function to call
// at compile-time based on `TypeId::of::<Self>`.
const CALL: fn(&Self) = {
const USIZE: TypeId = TypeId::of::<usize>();
match TypeId::of::<Self>() {
// Use a closure for `usize` that transmutes the generic `Self` to
// a concrete `usize` and dispatches to `Self::usize`.
USIZE => |x| Self::usize(unsafe { &*(x as *const Self as *const usize) }),
// For other types, dispatch to the generic `Self::default`.
_ => Self::default,
}
};
fn call(&self) {
// Call the function we determined at compile-time
(Self::CALL)(self)
}
fn default(x: &Self);
fn usize(x: &usize);
}
// Implement our `Specialized` trait for any `Debug` type.
impl<T: fmt::Debug + 'static> Specialized for T {
fn default(x: &Self) {
println!("default: {:?}", x);
}
fn usize(x: &usize) {
println!("usize: {:?}", x);
}
}
// Will print "usize: 42"
Specialized::call(&42usize);
// Will print "default: ()"
Specialized::call(&());
```
Type ids have some edges that this stabilization exposes to more contexts. It's possible for type ids to collide (but this is a bug). Since they can change between compiler versions, it's never valid to cast a type id to its underlying value.
|
|
add const generics array coercion test
|
|
|
|
|
|
|
|
|
|
Warn about unused expressions with closure or generator type. This follows
existing precedence of must use annotations present on `FnOnce`, `FnMut`, `Fn`
traits, which already indirectly apply to closures in some cases, e.g.,:
```rust
fn f() -> impl FnOnce() {
|| {}
}
fn main() {
// an existing warning: unused implementer of `std::ops::FnOnce` that must be used:
f();
// a new warning: unused closure that must be used:
|| {};
}
```
|
|
convert higher ranked `Predicate`s to `PredicateKind::ForAll`
implements step 2 of https://github.com/rust-lang/compiler-team/issues/285
r? @nikomatsakis
|
|
|
|
|
|
Forbid generic parameters in anon consts inside of type defaults
Emit a resolution error for `struct Foo<T, U = [u8; std::mem::size_of::<T>()]>`.
We are unable to support this with the way `ty::Generics` is currently used,
so let's just forbid it entirely for now.
Fixes some ICE on stable, e.g.
```rust
struct Foo<T, U = [u8; std::mem::size_of::<*mut T>()]>(T, U);
```
r? @varkor @eddyb
|
|
Make more primitive integer methods const
Now that #72437 has been merged and `const_if_match` is stable, these methods can be stabilized const. The methods are grouped in commits according to feature names:
* `const_nonzero_int_methods`
- `NonZero*::new`
* some `const_checked_int_methods`
- `{i*,u*}::checked_add`
- `{i*,u*}::checked_sub`
- `{i*,u*}::checked_mul`
- `{i*,u*}::checked_neg`
- `{i*,u*}::checked_shl`
- `{i*,u*}::checked_shr`
- `i*::checked_abs`
* `const_saturating_int_methods`
- `{i*,u*}::saturating_add`
- `{i*,u*}::saturating_sub`
- `{i*,u*}::saturating_mul`
- `i*::saturating_neg`
- `i*::saturating_abs`
* `const_int_sign`
- `i*::signum`
* `const_ascii_ctype_on_intrinsics`
- `{char,u8}::is_ascii_alphabetic`
- `{char,u8}::is_ascii_uppercase`
- `{char,u8}::is_ascii_lowercase`
- `{char,u8}::is_ascii_alphanumeric`
- `{char,u8}::is_ascii_digit`
- `{char,u8}::is_ascii_hexdigit`
- `{char,u8}::is_ascii_punctuation`
- `{char,u8}::is_ascii_graphic`
- `{char,u8}::is_ascii_whitespace`
- `{char,u8}::is_ascii_control`
|
|
|
|
|
|
Miri: replace canonical_alloc_id mechanism by extern_static_alloc_id
We only have to call `extern_static_alloc_id` when a `Pointer` is "imported" from the `tcx` to the machine, not on each access. Also drop the old hook for TLS handling, it is not needed any more.
The Miri side of this is at https://github.com/rust-lang/miri/pull/1489.
Fixes https://github.com/rust-lang/rust/issues/71194
r? @oli-obk
|
|
Rollup of 6 pull requests
Successful merges:
- #74088 (Avoid writes without any data in `Write::write_all_vectored`)
- #74598 (Fix sync_once_cell_does_not_leak_partially_constructed_boxes)
- #74750 (Clean up some uses of logging in ui tests)
- #74783 (python codes cleanup)
- #74790 (Don't italicize comments in ayu theme)
- #74799 (Fixed typo in `closure`)
Failed merges:
r? @ghost
|
|
Clean up some uses of logging in ui tests
The removed test can't possibly trigger anything today as we don't have logging in libstd.
The `exec-env` flag was mistakenly used for adding env vars to rustc invocations both in test and in the test suite and there were some accidental renames from RUST_LOG to RUSTC_LOG that I reverted.
|
|
Pull out some duplicated code into a new function
I debated pulling the actual struct_span_err calls into the new method, but I felt like having to pass in multiple arguments for it and wiring up string formatting outweighed the benefits.
Viewing the diff with whitespace ignored is recommended.
|
|
Fix #[track_caller] shims for trait objects.
We were missing an Instance::resolve_for_fn_ptr in resolve_for_vtable.
Closes #74764.
|
|
Serialize span hygiene data
Fixes #68686
Fixes #70963
This PR serializies global hygiene data into both the incremental compilation cache and the crate metadata. This allows hygiene information to be preserved across compilation sessions (both incremental and cross-crate).
When serializing a `SyntaxContext`, we simply write out the raw id from the current compilation session. Whenever we deserialize a `SyntaxContext`, we 'remap' the id to a fresh id in our current compilation session, and load the associated `SyntaxContextData`.
As a result, some 'upstream' `SyntaxContextData` will end up getting duplicated in 'downstream' crates. This only happens when we actually need to use an 'upstream' `SyntaxContext`, which occurs when we deserialize a `Span` that requires it.
We serialize an `ExpnData` into the metadata of the crate which generated it. An `ExpnId` is serialized as a reference into the crate which 'owns' the corresponding `ExpnData`, which avoids duplication in downstream crates.
I've included a macros 2.0 test which requires hygiene serialization to compile successfully.
TODO:
- [x] <strike>Determine how many additional `DefId`s we end up creating for `ExpnId`s - this may be significant for `libcore`, which uses macros heavily. Alternatively, we could try to compute a `DefPathHash` without making a corresponding `DefId` - however, this might significantly complicate the implementation.</strike> (We no longer create `DefId`s)
- [x] Investigate the overhead of duplicating `SyntaxContextData` in crate metadata.
- [x] Investigate how `resolve_crate_root` behaves with deserialized hygiene data - the current logic may be wrong.
- [x] Add additional tests. The effects of this PR are usually only noticeable when working with headache-inducing macro expansions (e.g. macros expanding to macros), so there are lots of corner cases to test.
- [x] Determine what to do about this:
https://github.com/rust-lang/rust/blob/4774f9b523c942cb5c0236542b5bcac76f6b6b9a/src/librustc_resolve/build_reduced_graph.rs#L892
- [x] Determine if we need to do anything here - I think the fact that `src/test/ui/hygiene/cross_crate_hygiene.rs` passes means that this is working.
https://github.com/rust-lang/rust/blob/3d5d0f898c2f3998e50c2180c6202f193c3acdbc/src/librustc_resolve/imports.rs#L1389-L1392
|
|
A raw SyntaxContext id is implicitly dependent on the target platform,
since libstd and libcore have platform-dependent #[cfg]s which affect
which macros are invoked. As a result, we must strip out any
SyntaxContext ids from test output to ensure that the captured stdout is
not platform-dependent.
|
