| Age | Commit message (Collapse) | Author | Lines |
|
fix static_ptr_ty for foreign statics
Cc https://github.com/rust-lang/rust/issues/74840
This does not fix that issue but fixes a problem in `static_ptr_ty` that we noticed while discussing that issue. I also added and updated a few comments. The one about `internal` locals being ignored does not seem to have been true [even in the commit that introduced it](https://github.com/rust-lang/rust/pull/44700/files#diff-ae2f3c7e2f9744f7ef43e96072b10e98d4e3fe74a3a399a3ad8a810fbe56c520R139).
r? @oli-obk
|
|
|
|
Optimize const value interning for ZST types
Interning can skip any inhabited ZST type in general.
Fixes #68010
r? @oli-obk
|
|
This optimization can result in unsoundness, because it introduces
additional uses of a place holding the discriminant value without
ensuring that it is valid to do so.
|
|
|
|
normalize substs while inlining
fixes #68347 or more precisely, this fixes the same ICE in rust analyser as veloren is pinned to a specific nightly
and had an error with the current one.
I didn't look into creating an MVCE here as that seems fairly annoying, will spend a few minutes doing so rn. (failed)
r? `@eddyb` cc `@bjorn3`
|
|
Clean up small, surprising bits of code
This PR clean up a small number of unrelated, small things I found while browsing the code base.
|
|
|
|
Interning can skip any inhabited ZST type in general.
|
|
Remove the old copy propagation pass
This pass was added a long time ago, and has not really seen much improvement since (apart from some great work in https://github.com/rust-lang/rust/pull/76569 that unfortunately ran into preexisting soundness issues). It is slow and unsound, and we now have a destination propagation pass that performs a related optimization and could be extended.
Closes https://github.com/rust-lang/rust/issues/36673
Closes https://github.com/rust-lang/rust/issues/73717
Closes https://github.com/rust-lang/rust/issues/76740
|
|
Permit uninhabited enums to cast into ints
This essentially reverts part of #6204; it is unclear why that [commit](https://github.com/rust-lang/rust/pull/6204/commits/c0f587de34f30b060df8a88c4068740e587b9340) was introduced, and I suspect no one remembers.
The changed code was only called from casting checks and appears to not affect any callers of that code (other than permitting this one case).
Fixes #75647.
|
|
|
|
instrument-coverage: try our best to not ICE
instrument-coverage was ICEing for me on some code, in particular code
that had devirtualized paths from standard library. Instrument coverage
probably has no bussiness dictating which paths are valid and which
aren't so just feed it everything and whatever and let tooling deal with
other stuff.
For example, with this commit we can generate coverage hitpoints for
these interesting paths:
* `/rustc/.../library/core/lib.rs` – non-devirtualized path for libcore
* `/home/.../src/library/core/lib.rs` – devirtualized version of above
* `<inline asm>`, `<anon>` and many similar synthetic paths
Even if those paths somehow get to the instrumentation pass, I'd much
rather get hits for these weird paths and hope some of them work (as
would be the case for devirtualized path to libcore), rather than have
compilation fail entirely.
|
|
instrument-coverage was ICEing for me on some code, in particular code
that had devirtualized paths from standard library. Instrument coverage
probably has no bussiness dictating which paths are valid and which
aren't so just feed it everything and whatever and let tooling deal with
other stuff.
For example, with this commit we can generate coverage hitpoints for
these interesting paths:
* `/rustc/.../library/core/lib.rs` – non-devirtualized path for libcore
* `/home/.../src/library/core/lib.rs` – devirtualized version of above
* `<inline asm>`, `<anon>` and many similar synthetic paths
Even if those paths somehow get to the instrumentation pass, I'd much
rather get hits for these weird paths and hope some of them work (as
would be the case for devirtualized path to libcore), rather than have
compilation fail entirely.
|
|
Create a single source scope for promoteds
A promoted inherits all scopes from the parent body. At the same time,
almost all statements and terminators inside the promoted body so far
refer only to one of those scopes: the outermost one.
Instead of inheriting all scopes, inherit only a single scope
corresponding to the location of the promoted, making sure that there
are no references to other scopes.
|
|
Preparation for a subsequent change that replaces
rustc_target::config::Config with its wrapped Target.
On its own, this commit breaks the build. I don't like making
build-breaking commits, but in this instance I believe that it
makes review easier, as the "real" changes of this PR can be
seen much more easily.
Result of running:
find compiler/ -type f -exec sed -i -e 's/target\.target\([)\.,; ]\)/target\1/g' {} \;
find compiler/ -type f -exec sed -i -e 's/target\.target$/target/g' {} \;
find compiler/ -type f -exec sed -i -e 's/target.ptr_width/target.pointer_width/g' {} \;
./x.py fmt
|
|
Validate references to source scopes
|
|
Remove needless alloc_slice
Don't invoke alloc_slice.
Arenas are temporary,
empty slices are eternal!
|
|
Don't invoke alloc_slice.
Arenas are temporary,
empty slices are eternal!
|
|
|
|
A promoted inherits all scopes from the parent body. At the same time,
almost all statements and terminators inside the promoted body so far
refer only to one of those scopes: the outermost one.
Instead of inheriting all scopes, inherit only a single scope
corresponding to the location of the promoted, making sure that there
are no references to other scopes.
|
|
|
|
Replace absolute paths with relative ones
Modern compilers allow reaching external crates
like std or core via relative paths in modules
outside of lib.rs and main.rs.
|
|
Modern compilers allow reaching external crates
like std or core via relative paths in modules
outside of lib.rs and main.rs.
|
|
Monomorphize `calculate_dtor` instead of using function pointers
Change `calculate_dtor` to avoid dynamic dispatching. This change allows the empty functions to be optimized away.
Based on the discussion in https://github.com/rust-lang/rust/pull/77754#discussion_r502498970, the performance impact of this change was measured.
Perf run results: https://perf.rust-lang.org/compare.html?start=7bc5839e99411aad9061a632b62075d1346cbb3b&end=ffec759ae9bbc4d6d2235ff40ade6723a85bc7cc
|
|
Refactor how SwitchInt stores jump targets
Closes https://github.com/rust-lang/rust/issues/65693
|
|
Mono collector: replace pair of ints with Range
I found the initial PR (#33171) that introduced this piece of code but I didn't find any information about why a tuple was preferred over a `Range<usize>`.
I'm hoping there are no technical reasons to not do this.
|
|
add shims for WithOptConstParam query calls
r? @ecstatic-morse @eddyb
|
|
Recognize discriminant reads as no-ops in RemoveNoopLandingPads
The cleanup blocks often contain read of discriminants. Teach
RemoveNoopLandingPads to recognize them as no-ops to remove
additional no-op landing pads.
|
|
This allows building common SwitchTargets (eg. for `if`s) without
allocation.
|
|
|
|
|
|
|
|
The cleanup blocks often contain read of discriminants. Teach
RemoveNoopLandingPads to recognize them as no-ops to remove
additional no-op landing pads.
|
|
|
|
|
|
Fix a typo: minding -> binding
Add test for &mut &mut
|
|
Use `pretty::create_dump_file` for dumping dataflow results
The old code wasn't incorporating promoteds into the path, meaning other `dot` files could get clobbered. Use the MIR dump infrastructure to generate paths so that this doesn't occur in the future.
|
|
perf: UninhabitedEnumBranching avoid n^2
Avoid n² complexity. This showed up in a profile for match-stress-enum that has 8192 variants
I have only profiled locally against `match-stress-enum`, so we should have it perf tested to make sure it does not regress other crates.
|
|
Avoid n² complexity. This showed up in a profile for match-stress-enum that has 8192 variants
|
|
Give `impl Trait` in a `const fn` its own feature gate
...previously it was gated under `#![feature(const_fn)]`.
I think we actually want to do this in all const-contexts? If so, this should be `#![feature(const_impl_trait)]` instead. I don't think there's any way to make use of `impl Trait` within a `const` initializer.
cc #77463
r? `@oli-obk`
|
|
|
|
r=wesleywiser
Move `EarlyOtherwiseBranch` to mir-opt-level 2
cc #75119
This didn't have an [effect in most cases](https://perf.rust-lang.org/compare.html?start=81e02708f1f4760244756548981277d5199baa9a&end=2e0edc0f28c5647141bedba02e7a222d3a5dc9c3&stat=instructions:u), and is not trivially sound. Let it bake at `mir-opt-level=2` for a while.
Also, this missed the cutoff for beta, so we'll have to backport this.
r? @wesleywiser
|
|
inliner: use caller param_env
We used the callee param env instead of the caller param env by accident in #77430, this PR fixes that and caches it in the `Inliner` struct.
fixes #77564
r? @ecstatic-morse
|
|
|
|
r=lcnr
Fix rustdoc warnings about invalid Rust syntax
|
|
|
|
|
|
|
|
|