| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Use `ptr::eq` where applicable
Stumbled upon a few of `A as *const _ as usize == B as *const as usize`, so I decided to follow the programming boy scout rule (:smile:) and replaced the pattern with more widely used `ptr::eq`.
|
|
Speed up item_bodies for large match statements involving regions
These changes don't change anything about the complexity of the algorithms, but use some easy shortcuts or modifications to cut down some overhead.
The first change, which incrementally removes the constraints from the set we're iterating over probably introduces some overhead for small to medium sized constraint sets, but it's not big enough for me to observe it in any project I tested against (not that many though).
Though most other crates probably won't improve much at all, because huge matches aren't that common, the changes seemed simple enough for me to make them.
Ref #55528
cc unicode-rs/unicode-normalization#29
r? @nikomatsakis
|
|
Stabilize `uniform_paths`
Address all the things described in https://github.com/rust-lang/rust/issues/56417.
Assign visibilities to `macro_rules` items - `pub` to `macro_export`-ed macros and `pub(crate)` to non-exported macros, these visibilities determine how far these macros can be reexported with `use`.
Prohibit use of reexported inert attributes and "tool modules", after renaming (e.g. `use inline as imported_inline`) their respective tools and even compiler passes won't be able to recognize and properly check them.
Also turn use of uniform paths in 2015 macros into an error, I'd prefer to neither remove nor stabilize them right away because I still want to make some experiments in this area (uniform path fallback was added to 2015 macros used on 2018 edition in https://github.com/rust-lang/rust/pull/56053#issuecomment-441405140).
UPDATE: The last commit also stabilizes the feature `uniform_paths`.
Closes https://github.com/rust-lang/rust/issues/53130
Closes https://github.com/rust-lang/rust/issues/55618
Closes https://github.com/rust-lang/rust/issues/56326
Closes https://github.com/rust-lang/rust/issues/56398
Closes https://github.com/rust-lang/rust/issues/56417
Closes https://github.com/rust-lang/rust/issues/56821
Closes https://github.com/rust-lang/rust/issues/57252
Closes https://github.com/rust-lang/rust/issues/57422
|
|
|
|
|
|
Stabilise irrefutable if-let and while-let patterns
This stabilises RFC 2086 (https://github.com/rust-lang/rust/issues/44495).
This replaces https://github.com/rust-lang/rust/pull/55639, as we want to stabilise this in time for the beta cut-off.
Closes https://github.com/rust-lang/rust/pull/55639.
r? @Centril
|
|
Remove `CrateNum::Invalid`.
It's unused.
|
|
pnkfelix:issue-57038-sidestep-ice-in-fieldplacement-count, r=michaelwoerister
Don't call `FieldPlacement::count` when count is too large
Sidestep ICE in `FieldPlacement::count` by not calling it when count will not fit in host's usize.
(I briefly played with trying to fix this by changing `FieldPlacement::count` to return a `u64`. However, based on how `FieldPlacement` is used, it seems like this would be a largely pointless pursuit... I'm open to counter-arguments, however.)
Fix #57038
|
|
Issue #56905
Adding a map to TypeckTables to get the list of all the Upvars
given a closureID. This is help us get rid of the recurring
pattern in the codebase of iterating over the free vars
using with_freevars.
|
|
This stabilises RFC 2086 (https://github.com/rust-lang/rust/issues/44495).
Co-Authored-By: Sebastian Malton <sebastian@malton.name>
|
|
use the correct supertrait substitution in `object_ty_for_trait`
beta-nominating because regression.
Fixes #57156.
|
|
In functions with lots of region constraint, if the fixed point
iteration converges only slowly, a lot of the var/var constraints will
have equal regions most of the time. Yet, we still perform the LUB
calculation and try to intern the result. Especially the latter incurs
quite some overhead.
This reduces the take taken by the item bodies checking pass for the
unicode_normalization crate by about 75%.
|
|
Once a region has been expanded to cover a fixed region, a corresponding
RegSubVar constraint won't have any effect on the expansion anymore, the
same is true for constraints where the variable on the RHS has already
reached static scope. By removing those constraints from the set that
we're iterating over, we remove a lot of needless overhead in case of
slow convergences (i.e. lots of iterations).
For the unicode_normalization crate, this about cuts the time required
for item_bodies checking in half.
|
|
Replace LockCell with atomic types
Split from https://github.com/rust-lang/rust/pull/56509
r? @michaelwoerister
|
|
Currently, there are many places in rustc, where we use
with_freevars to iterate over freevars of a closure. The
problem with this is the argument to with_freevars is a
NodeId and this will get in the way of our eventual goal
of solving for issue (#53488), sub-issue (#56905)
|
|
Change the key of UpvarListMap from DefId to ast::NodeId
|
|
Adding a map to TypeckTables to get the list of all the Upvars
given a closureID. This is help us get rid of the recurring
pattern in the codebase of iterating over the free vars
using with_freevars.
|
|
Clean up and optimize OpenTask / read_index
r? @michaelwoerister
|
|
std: Force `Instant::now()` to be monotonic
This commit is an attempt to force `Instant::now` to be monotonic
through any means possible. We tried relying on OS/hardware/clock
implementations, but those seem buggy enough that we can't rely on them
in practice. This commit implements the same hammer Firefox recently
implemented (noted in #56612) which is to just keep whatever the lastest
`Instant::now()` return value was in memory, returning that instead of
the OS looks like it's moving backwards.
Closes #48514
Closes #49281
cc #51648
cc #56560
Closes #56612
Closes #56940
|
|
It's unused.
|
|
Fix and optimize query profiling
r? @michaelwoerister
cc @wesleywiser
|
|
submodules: update clippy and rls
Fixes clippy toolstate
Changes:
````
Update to latest compiletest-rs release
add testcase for #3462
deps: bump rustc_tools_util version from 0.1.0 to 0.1.1 just in case...
rustc_tool_utils: fix failure to create proper non-repo version string when used in crates on crates.io, bump version
UI test cleanup: Extract ifs_same_cond tests
UI test cleanup: Extract for_kv_map lint tests
Fix test for rust-lang/rust#57250
Limit infinite_iter collect() check to known types
Some improvements to util documentation
Use hashset for name blacklist
Reformat random_state tests
Use node_id_to_type_opt instead of node_it_to_type in random_state
Check pattern equality while checking declaration equality
random_state lint
Use an FxHashSet for valid idents in documentation lint
Fix suggestion for unnecessary_ref lint
Update CONTRIBUTING.md for rustfix tests
Update .fixed files via update-references.sh
Run rustfix on first UI test
Use WIP branch for compiletest_rs
````
Also updates RLS and removes the patching of rustc_tool_utils from cargo.toml
RLS changes:
````
update clippy hash and rustc_tools_util and use rustc_tools_util from crates.io
Work around https://github.com/rust-lang/rust/pull/55937
Update Clippy... again
Update Clippy
Update clippy
````
r? @oli-obk
|
|
This reverts commit 68614265d312fc2cbe8a696f7dabb9416eb6f221, reversing
changes made to cae623c5ce12df8f237264d8f2c31fdaa664c382.
Should fix tools on windows.
Reopens #57014
|
|
|
|
|
|
This commit is an attempt to force `Instant::now` to be monotonic
through any means possible. We tried relying on OS/hardware/clock
implementations, but those seem buggy enough that we can't rely on them
in practice. This commit implements the same hammer Firefox recently
implemented (noted in #56612) which is to just keep whatever the lastest
`Instant::now()` return value was in memory, returning that instead of
the OS looks like it's moving backwards.
Closes #48514
Closes #49281
cc #51648
cc #56560
Closes #56612
Closes #56940
|
|
remove outdated comment
https://github.com/rust-lang/rust/issues/44234 was closed, apparently solved by #45353
r? @michaelwoerister
|
|
|
|
Modify mismatched type error for functions with no return
Fix #50009.
```
error[E0308]: mismatched types
--> $DIR/coercion-missing-tail-expected-type.rs:3:24
|
LL | fn plus_one(x: i32) -> i32 { //~ ERROR mismatched types
| -------- ^^^ expected i32, found ()
| |
| this function's body doesn't return
LL | x + 1;
| - help: consider removing this semicolon
|
= note: expected type `i32`
found type `()`
```
instead of
```
error[E0308]: mismatched types
--> $DIR/coercion-missing-tail-expected-type.rs:3:28
|
LL | fn plus_one(x: i32) -> i32 { //~ ERROR mismatched types
| ____________________________^
LL | | x + 1;
| | - help: consider removing this semicolon
LL | | }
| |_^ expected i32, found ()
|
= note: expected type `i32`
found type `()`
```
|
|
Fixes #57156.
|
|
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.
|
|
Fix #56806 by using `delay_span_bug` in object safety layout sanity checks
It's possible that `is_object_safe` is called on a trait method that with an invalid receiver type. This caused an ICE in #56806, because `receiver_is_dispatchable` returns `true` for `self: Box<dyn Trait>`, which causes one of the layout sanity checks in object_safety.rs to fail. Replacing `bug!` with `delay_span_bug` solves this.
The fact that `receiver_is_dispatchable` returns `true` here could be considered a bug. It passes the check that the method implements, though: `Box<dyn Trait>` implements `DispatchFromDyn<Box<dyn Trait>>` because `dyn Trait` implements `Unsize<dyn Trait>`. It would be good to hear what @eddyb and @nikomatsakis think.
Note that I only added a test for the case encountered in #56806. I could not come up with a case that triggered an ICE from the other check, `bug!("receiver when Self = dyn Trait should be ScalarPair, found Scalar")`. There is no way, to my knowledge, that you can make `receiver_is_dispatchable` return true but still have a `Scalar` ABI when `Self = dyn Trait`.
One other case I encountered while debugging #56806 was that if you have a type parameter `T` that implements `Deref<Target=Self>` and `DispatchFromDyn<T>`, and use it as a method receiver, it will cause an ICE during `is_object_safe` because `T` has no layout ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=d9b7497b3be0ca8382fa7d9497263214)):
```rust
trait Trait<T: Deref<Target=Self> + DispatchFromDyn<T>> {
fn foo(self: T) -> dyn Trait<T>;
}
```
I don't intend to remove the ICE there because it is a pathological case, especially since there is no way to implement `DispatchFromDyn<T>` for `T` — the checks in typeck/coherence/builtin.rs do not allow that.
fixes #56806
r? @varkor
|
|
Remove some unused code
Closes #57096
|
|
Search codegen backends based on target libdir instead of sysroot
Fixes #57014
Fixes cases with custom libdir when it consists of two or more parts.
|
|
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
|
|
Implement the Re-rebalance coherence RFC
This is the first time I touch anything in the compiler so just tell me if I got something wrong.
Big thanks to @sgrif for the pointers where to look for those things.
cc #55437
|
|
It's possible that `is_object_safe` is called on a trait that is ill-formed, and we shouldn't ICE unless there are no errors being raised. Using `delay_span_bug` solves this.
fixes #56806
|
|
|
|
|
|
Co-Authored-By: wiktorkuchta <35867657+wiktorkuchta@users.noreply.github.com>
|
|
Don't emit `Unevaluated` from `const_eval`
cc @eddyb @RalfJung
|
|
This makes sure they are printed in a compiler-version-independent
order, avoiding ui test instability.
|
|
|
|
This reverts commit 760639635facb6c9a0926ac9278bcba71880b0b3.
|
|
|
|
|
|
Fixes #33140.
|
|
should be a pure refactoring.
|
