| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Fixes #75144
|
|
change offset from u32 to u64
References #71696
r? @oli-obk
(closed the earlier pr because the rebase got messed up)
|
|
This commit adjusts the naming of various lang items so that they are
consistent and don't include prefixes containing the target or
"LangItem". In addition, lang item variants are no longer exported from
the `lang_items` module.
Signed-off-by: David Wood <david@davidtw.co>
|
|
|
|
Check that we don't use `Rvalue::Aggregate` after the deaggregator
fixes #75481
r? @wesleywiser
cc @RalfJung (modified the validator)
|
|
Co-authored-by: Wesley Wiser <wwiser@gmail.com>
|
|
Moved coverage counter injection from BasicBlock to Statement.
As discussed on Zulip: https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Implement.20LLVM-compatible.20source-based.20cod.20compiler-team.23278
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #75389 (attempt to improve span_label docs)
- #75392 (Add `as_uninit`-like methods to pointer types and unify documentation of `as_ref` methods)
- #75464 (Move to intra doc links for ascii.rs and panic.rs)
- #75578 (Allowing raw ptr dereference in const fn)
- #75613 (Add explanation for `&mut self` method call when expecting `-> Self`)
- #75626 (Clean up E0754 explanation)
- #75629 (Use intra-doc links in `std::env`, `std::alloc` and `std::error`)
- #75634 (Mark x86_64-linux-kernel as *)
Failed merges:
r? @ghost
|
|
Allowing raw ptr dereference in const fn
Reflect on issue #75340
Discussion in previous PR #75425
## Updates
Change `UnsafetyViolationKind::General` to `UnsafetyViolationKind::GeneralAndConstFn` in check_unsafety.rs
Remove `unsafe` in min_const_fn_unsafe_bad.rs
Bless min_const_fn
Add the test case from issue 75340
***
Sorry for the chaos. I messed up and ended up deleting the repo in the last PR. I have to create a new PR for the new repo. I will make a feature branch next time. I will edit the old PR once I receive the commends.
@RalfJung Thank you all for your replies. They are helpful!
r? @oli-obk
|
|
rust_ast::ast => rustc_ast
Rework of #71199 which is a rework #70621
Still working on this but just made the PR to track progress
r? @Dylan-DPC
|
|
|
|
Change `UnsafetyViolationKind::General` to `UnsafetyViolationKind::GeneralAndConstFn` in check_unsafety.rs
Remove unsafe in min_const_fn_unsafe_bad.rs
Bless min_const_fn
Add the test case from issue 75340
Co-authored-by: lzutao <taolzu@gmail.com>
|
|
and `discriminant(_0) = discriminant(0)` are considered equal if 0 is a fieldless variant of an enum
|
|
MatchBranchSimplification: fix equal const bool assignments
The match branch simplification is applied when target blocks contain
statements that are either equal or perform a const bool assignment with
different values to the same place.
Previously, when constructing new statements, only statements from a
single block had been examined. This lead to a misoptimization when
statements are equal because the assign the *same* const bool value to
the same place.
Fix the issue by examining statements from both blocks when deciding on
replacement.
Additionally:
* Copy discriminant instead of moving it since it might be necessary to use its
value more than once.
* Optimize when switching on copy operand
Based on #75508.
r? @oli-obk / @JulianKnodt
|
|
merge `as_local_hir_id` with `local_def_id_to_hir_id`
`as_local_hir_id` was defined as just calling `local_def_id_to_hir_id` and I think that having two different ways to call the same method is somewhat confusing.
Don't really care about which of these 2 methods we want to keep.
Does this require an MCP, considering that these methods are fairly frequently used?
|
|
|
|
The match branch simplification is applied when target blocks contain
statements that are either equal or perform a const bool assignment with
different values to the same place.
Previously, when constructing new statements, only statements from a
single block had been examined. This lead to a misoptimization when
statements are equal because the assign the *same* const bool value to
the same place.
Fix the issue by examining statements from both blocks when deciding on
replacement.
|
|
Promotion and const interning comments
I understood some things today which I felt should be put into comments.
Cc @rust-lang/wg-const-eval
|
|
It might be necessary to use its value more than once.
|
|
|
|
LLVM IR coverage encoding aligns closer to Clang's
I found some areas for improvement while attempting to debug the
SegFault issue when running rust programs compiled using MSVC, with
coverage instrumentation.
I discovered that LLVM's coverage writer was generating incomplete
function name variable names (that's not a typo: the name of the
variable that holds a function name).
The existing implementation used one-up numbers to distinguish
variables, and correcting the names did not fix the MSVC coverage bug,
but the fix in this PR makes the names and resulting LLVM IR easier to
follow and more consistent with Clang's implementation.
I also changed the way the `-Zinstrument-coverage` option is supported in
symbol_export.rs. The original implementation was incorrect, and the
corrected version matches the handling for `-Zprofile-generate`, as it
turns out.
(An argument could be made that maybe `-Zinstrument-coverage` should
automatically enable `-Cprofile-generate`. In fact, if
`-Cprofile-generate` is analagous to Clang's `-fprofile-generate`, as
some documentation implies, Clang always requires this flag for its
implementation of source-based code coverage. This would require a
little more validation, and if implemented, would probably require
updating some of the user-facing messages related to
`-Cprofile-generate` to not be so specific to the PGO use case.)
None of these changes fixed the MSVC coverage problems, but they should
still be welcome improvements.
Lastly, I added some additional FIXME comments in instrument_coverage.rs
describing issues I found with the generated LLVM IR that would be
resolved if the coverage instrumentation is injected with a `Statement`
instead of as a new `BasicBlock`. I describe seven advantages of this
change, but it requires some discussion before making a change like
this.
r? @tmandry
|
|
I found some areas for improvement while attempting to debug the
SegFault issue when running rust programs compiled using MSVC, with
coverage instrumentation.
I discovered that LLVM's coverage writer was generating incomplete
function name variable names (that's not a typo: the name of the
variable that holds a function name).
The existing implementation used one-up numbers to distinguish
variables, and correcting the names did not fix the MSVC coverage bug,
but the fix in this PR makes the names and resulting LLVM IR easier to
follow and more consistent with Clang's implementation.
I also changed the way the `-Zinstrument-coverage` option is supported
in symbol_export.rs. The original implementation was incorrect, and the
corrected version matches the handling for `-Zprofile-generate`, as it
turns out.
(An argument could be made that maybe `-Zinstrument-coverage` should
automatically enable `-Cprofile-generate`. In fact, if
`-Cprofile-generate` is analagous to Clang's `-fprofile-generate`, as
some documentation implies, Clang always requires this flag for its
implementation of source-based code coverage. This would require a
little more validation, and if implemented, would probably require
updating some of the user-facing messages related to
`-Cprofile-generate` to not be so specific to the PGO use case.)
None of these changes fixed the MSVC coverage problems, but they should
still be welcome improvements.
Lastly, I added some additional FIXME comments in instrument_coverage.rs
describing issues I found with the generated LLVM IR that would be
resolved if the coverage instrumentation is injected with a `Statement`
instead of as a new `BasicBlock`. I describe seven advantages of this
change, but it requires some discussion before making a change like
this.
|
|
Clean up some mir transform passes
I noticed a few places where there were intermediates being created
in MIR optimization passes, so I removed them.
I also changed some `Some(..)` into just `..` and wrap `Some(..)` at the function end, doing early returns for `None`.
I was generally looking for some easy optimizations in theses passes, and hopefully these should improve the runtime of these passes by a tinnnyyyyy bit.
r? @oli-obk
|
|
|
|
Also convert `uninhabited_enum_branching` `Cow<[u128]>::to_mut`
|
|
This also explicitly checks that the types are `bool`. `try_eval_bool` also appears to just
succeed for `u8`, so this ensures that it actually is a bool before casting.
|
|
I noticed a few places where there were intermediates being created
in MIR optimization passes, so I removed them.
|
|
|
|
Just output the current bless'd MIR diff
The tests are still fairly broken rn
|
|
|
|
This also updates a check to ensure that this is only applied to bools
|
|
|
|
|
|
|
|
move Deaggregate pass to post_borrowck_cleanup
Reopen of #71946
Only the second commit is from this PR, the other commit is a bugfix that's in the process of getting merged. I'll rebase once that's done
In #70073 MIR pass handling got reorganized, but with the goal of not changing behavior (except for disabling some optimizations on opt-level = 0). But there we realized that the Deaggregator pass, while conceptually more of a "cleanup" pass (and one that should be run before optimizations), was run in the middle of the optimization chain. Likely this is an accident of history, so I suggest we try and clean that up by making it a proper cleanup pass.
This does change mir-opt output, because deaggregation now runs before const-prop instead of after.
r? @wesleywiser @rust-lang/wg-mir-opt
cc @RalfJung
|
|
|
|
Miri: Renamed "undef" to "uninit"
Renamed remaining references to "undef" to "uninit" when referring to Miri.
Impacted directories are:
- `src/librustc_codegen_llvm/consts.rs`
- `src/librustc_middle/mir/interpret/`
- `src/librustc_middle/ty/print/pretty.rs`
- `src/librustc_mir/`
- `src/tools/clippy/clippy_lints/src/consts.rs`
Upon building Miri based on the new changes it was verified that no changes needed to be made with the Miri project.
Related issue #71193
|
|
|
|
Renamed remaining references to "undef" to "uninit" when referring to Miri.
Impacted directories are:
- src/librustc_codegen_llvm/consts.rs
- src/librustc_middle/mir/interpret/
- src/librustc_middle/ty/print/pretty.rs
- src/librustc_mir/
- src/tools/clippy/clippy_lints/src/consts.rs
Upon building Miri based on the new changes it was verified that no changes needed to be made with the Miri project.
Related issue #71193
|
|
Remove `librustc_ast` session globals
By moving the data onto `Session`.
r? @petrochenkov
|
|
By moving `{known,used}_attrs` from `SessionGlobals` to `Session`. This
means they are accessed via the `Session`, rather than via TLS. A few
`Attr` methods and `librustc_ast` functions are now methods of
`Session`.
All of this required passing a `Session` to lots of functions that didn't
already have one. Some of these functions also had arguments removed, because
those arguments could be accessed directly via the `Session` argument.
`contains_feature_attr()` was dead, and is removed.
Some functions were moved from `librustc_ast` elsewhere because they now need
to access `Session`, which isn't available in that crate.
- `entry_point_type()` --> `librustc_builtin_macros`
- `global_allocator_spans()` --> `librustc_metadata`
- `is_proc_macro_attr()` --> `Session`
|
|
|
|
|
|
Check whether locals are too large instead of whether accesses into them are too large
Essentially this stops const prop from attempting to optimize
```rust
let mut x = [0_u8; 5000];
x[42] = 3;
```
I don't expect this to be a perf improvement without #73656 (which is also where the lack of this PR will be a perf regression).
r? @wesleywiser
|
