| Age | Commit message (Collapse) | Author | Lines |
|
remove outdated comment
https://github.com/rust-lang/rust/issues/44234 was closed, apparently solved by #45353
r? @michaelwoerister
|
|
|
|
Calculate privacy access only via query
Initially converted to query in https://github.com/rust-lang/rust/commit/a9f6babcda1479f4e5566d1aadbf9a0d99aa3182 and then changed to respect dependencies https://github.com/rust-lang/rust/commit/8281e883dd12260f00ce650aa8824507d9c447af.
I did this as an effort to prune `CrateAnalysis` from librustc_save_analysis, with the only thing remaining being the glob map (`name` is unused, existing `crate_name` is exposed in the compiler passes, instead).
Since calculating the glob map is opt-in, it'd be great if we could calculate that on-demand. However, it seems that it'd require converting resolution to queries, which I'm not sure how to do yet.
In an effort to get rid of `CrateAnalysis` altogether, could we try unconditionally calculating the glob_map in the resolver, thus completely removing `CrateAnalysis` struct, and doing a perf run?
r? @nikomatsakis
cc @petrochenkov do you have any idea how/if at all could we querify the resolver? I've stumbled upon a comment that's ~3? years old at the moment, so I'm guessing things might have changed and it actually may be feasible now. https://github.com/rust-lang/rust/blob/fe0c10019d7ee96909cc42cc265ef999a6b5dd70/src/librustc_driver/driver.rs#L589-L593
|
|
Fix repeated word typos
Inspired by #57295 (I skipped 'be be' because of it) and my [PR in another repo
](https://github.com/e-maxx-eng/e-maxx-eng/pull/389)
Not a stupid `sed`, I actually tried to fix case by case.
|
|
Fix 'be be' constructs
I noticed a duplicated "be" somewhere in the code. A search for it
manifested a couple more locations with the same problem. This change
removes one of the "be"s.
|
|
Add support for trait-objects without a principal
The hard-error version of #56481 - should be merged after we do something about the `traitobject` crate.
Fixes #33140.
Fixes #57057.
r? @nikomatsakis
|
|
|
|
|
|
Co-Authored-By: wiktorkuchta <35867657+wiktorkuchta@users.noreply.github.com>
|
|
Don't emit `Unevaluated` from `const_eval`
cc @eddyb @RalfJung
|
|
|
|
This reverts commit 760639635facb6c9a0926ac9278bcba71880b0b3.
|
|
|
|
Fixes #33140.
|
|
should be a pure refactoring.
|
|
There is no type T, such that `T = [T; 2]`, we should not allow this
to be circumvented by impl Trait.
|
|
Found with `git grep -P '\b([a-z]+)\s+\1\b'`
|
|
I noticed a duplicated "be" somewhere in the code. A search for it
manifested a couple more locations with the same problem. This change
removes one of the "be"s.
|
|
|
|
|
|
|
|
Still not great, but good enough to land this PR.
|
|
Previously, evaluation ignored outlives relationships. Since we using
evaluation to skip the "normal" trait selection (which enforces
outlives relationships) this led to incorrect results in some cases.
|
|
|
|
Improve type mismatch error messages
Closes #56115.
Replace "integral variable" with "integer" and replace "floating-point variable" with "floating-point number" to make the message less confusing.
TODO the book and clippy needs to be changed accordingly later.
r? @varkor
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NLL: User type annotations refactor, associated constant patterns and ref bindings.
Fixes #55511 and Fixes #55401. Contributes to #54943.
This PR performs a large refactoring on user type annotations, checks user type annotations for associated constants in patterns and that user type annotations for `ref` bindings are respected.
r? @nikomatsakis
|
|
Replace "integral variable" with "integer" and replace
"floating-point variable" with "floating-point number" to make the
message less confusing.
|
|
|
|
Uninline some debugging code and use unlikely! macro
r? @michaelwoerister
|
|
This commit stops well-formedness checking applying to unreachable code
and therefore stops some of the ICEs that the intended solution taken by
this PR causes.
By disabling these checks, we can land the other fixes and larger
refactors that this PR includes.
|
|
This commit uses the map introduced by the previous commit to ensure
that types are always checked for well-formedness by the NLL type check.
Previously, without the map introduced by the previous commit, types
would not be checked for well-formedness if the `AscribeUserType`
statement that would trigger that check was removed as unreachable code.
|
|
This commit refactors the `UserTypeAnnotation` type to be referred to by
an index within `UserTypeProjection`. `UserTypeAnnotation` is instead
kept in an `IndexVec` within the `Mir` struct.
Further, instead of `UserTypeAnnotation` containing canonicalized types,
it now contains normal types and the entire `UserTypeAnnotation` is
canonicalized. To support this, the type was moved from the `rustc::mir`
module to `rustc::ty` module.
|
|
Suggest `.as_ref()` when appropriate for `Option` and `Result`
Fix #55198.
|
|
Implement RFC 2338, "Type alias enum variants"
This PR implements [RFC 2338](https://github.com/rust-lang/rfcs/pull/2338), allowing one to write code like the following.
```rust
#![feature(type_alias_enum_variants)]
enum Foo {
Bar(i32),
Baz { i: i32 },
}
type Alias = Foo;
fn main() {
let t = Alias::Bar(0);
let t = Alias::Baz { i: 0 };
match t {
Alias::Bar(_i) => {}
Alias::Baz { i: _i } => {}
}
}
```
Since `Self` can be considered a type alias in this context, it also enables using `Self::Variant` as both a constructor and pattern.
Fixes issues #56199 and #56611.
N.B., after discussing the syntax for type arguments on enum variants with @petrochenkov and @eddyb (there are also a few comments on the [tracking issue](https://github.com/rust-lang/rust/issues/49683)), the consensus seems to be treat the syntax as follows, which ought to be backwards-compatible.
```rust
Option::<u8>::None; // OK
Option::None::<u8>; // OK, but lint in near future (hard error next edition?)
Alias::<u8>::None; // OK
Alias::None::<u8>; // Error
```
I do not know if this will need an FCP, but let's start one if so.
|
|
|
|
Add a command line flag to print some query stats
r? @michaelwoerister
|
|
|
|
|
|
Multiple references to the same `BoundTy` were not using the same
result.
|