| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This reverts commit a8ecb79d19e1bad732dae7f34f2481499db12f7c, reversing
changes made to 40c4e05013c1805044ae2611ba0b95c0acecd331.
(cherry picked from commit 9ea587e023dfa4458c5003ba74ae02bd146ec2df)
|
|
(cherry picked from commit 4c939db0e775df21a0b409b7603eaaf0056e8f86)
|
|
(cherry picked from commit 039af88e09f4f4beb47406f4771bffc2e61d800a)
|
|
(cherry picked from commit b6f22400002f7921feed13e35852e3041cf2b145)
|
|
This reverts commit a7a6c64a657f68113301c2ffe0745b49a16442d1, reversing
changes made to ebbe63891f1fae21734cb97f2f863b08b1d44bf8.
(cherry picked from commit a59a8f9e7579b4346eb6b00c3809d04986dcfcee)
|
|
(cherry picked from commit fbe0075a86601e490ae217f3b291768759c39930)
|
|
(cherry picked from commit 8089fce101f4ac2ed68c8df080c61102b0210429)
|
|
(cherry picked from commit bad8e98c7d0ed217b58362e61ae4357e5344d995)
|
|
(cherry picked from commit 2797936f6dcd29777f236a5d966d487a7f4cbbb3)
|
|
(cherry picked from commit bab03bf1768fea8512ece42dea6d66f6f4743145)
|
|
As an i586 target, it should not have SSE. This caused the following
warning to be emitted:
```
warning: target feature `sse2` must be enabled to ensure that the ABI of the current target can be implemented correctly
|
= note: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #116344 <https://github.com/rust-lang/rust/issues/116344>
warning: 1 warning emitted
```
(cherry picked from commit 1c66d5bed9e6444923c04937f5a28bfcec427ec0)
|
|
|
|
made check_argument_compat public for use in miri
Links to [issue](https://github.com/rust-lang/miri/issues/3842) and it's [PR](https://github.com/rust-lang/miri/pull/4185#issuecomment-2657554989) in miri.
|
|
r=jieyouxu,compiler-errors
Remove unnecessary check code in unused_delims
After PR #108297, we make sure there is no unmatched delims in early lint check.
|
|
mir_build: Clarify some code for lowering `hir::PatExpr` to THIR
A few loosely-related improvements to the code that lowers certain parts of HIR patterns to THIR.
I was originally deferring this until after #136529, but that PR probably won't happen, whereas these changes should hopefully be uncontroversial.
r? Nadrieril or reroll
|
|
|
|
|
|
|
|
add x86-sse2 (32bit) ABI that requires SSE2 target feature
This is the first commit of https://github.com/rust-lang/rust/pull/135408:
The primary goal of this is to make SSE2 required for our i686 targets (at least for the ones that use Pentium 4 as their baseline), to ensure they cannot be affected by https://github.com/rust-lang/rust/issues/114479. This has been MCPd in https://github.com/rust-lang/compiler-team/issues/808, and is tracked in https://github.com/rust-lang/rust/issues/133611.
We do this by defining a new ABI that these targets select, and making SSE2 required by the ABI (that's the first commit). That's kind of a hack, but it is the easiest way to make a target feature required via the target spec. In a follow-up change (https://github.com/rust-lang/rust/pull/135408), we can actually make use of SSE2 for the ABI, but that is running into some infrastructure issues.
r? `@workingjubilee`
try-job: aarch64-apple
try-job: aarch64-gnu
try-job: aarch64-gnu-debug
try-job: test-various
try-job: x86_64-gnu-nopt
try-job: dist-i586-gnu-i586-i686-musl
|
|
r=saethlin
Normalize closure instance before eagerly monomorphizing it
We were monomorphizing two versions of the closure (or in the original issue, coroutine) -- one with normalized captures and one with unnormalized captures. This led to a symbol collision.
Fixes #137009
r? `@saethlin` or reassign
|
|
Decode metadata buffer in one go
Not sure if this is perf relevant at all, but it was a bit odd before
r? ``@the8472``
|
|
borrowck diagnostics cleanup: remove an unused and a barely-used field
This removes the fields `fr_is_local` and `outlived_fr_is_local` from the struct `ErrorConstraintInfo`. `fr_is_local` was fully unused, but wasn't caught by dead-code analysis. For symmetry, and since `outlived_fr_is_local` was used only once and is easy to recompute, I've removed it too. That makes its one use a bit longer, but constructing/destructuring an `ErrorConsraintInfo` now fits on one line.
|
|
r=compiler-errors
Fix early lint check desc in query
When I debugging this issue: https://github.com/rust-lang/rust/pull/136906#discussion_r1954151036
I found early lint checking is performed after [macro expansion](https://github.com/chenyukang/rust/blob/37520e6d89eeea96b966ab281a7adf1775f7e207/compiler/rustc_interface/src/passes.rs#L267), but [prior to AST lowering](https://github.com/chenyukang/rust/blob/37520e6d89eeea96b966ab281a7adf1775f7e207/compiler/rustc_ast_lowering/src/lib.rs#L427).
r? ``@cjgillot``
|
|
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #135778 (account for `c_enum_min_bits` in `multiple-reprs` UI test)
- #136052 (Correct comment for FreeBSD and DragonFly BSD in unix/thread)
- #136886 (Remove the common prelude module)
- #136956 (add vendor directory to .gitignore)
- #136958 (Fix presentation of purely "additive" replacement suggestion parts)
- #136967 (Use `slice::fill` in `io::Repeat` implementation)
- #136976 (alloc boxed: docs: use MaybeUninit::write instead of as_mut_ptr)
- #137007 (Emit MIR for each bit with on `dont_reset_cast_kind_without_updating_operand`)
- #137008 (Move code into `rustc_mir_transform`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
r=oli-obk
Move code into `rustc_mir_transform`
I found two modules in other crates that are better placed in `rustc_mir_transform`, because that's the only crate that uses them.
r? ``@matthewjasper``
|
|
Fix presentation of purely "additive" replacement suggestion parts
#127541 changes replacement suggestions to use the "diff" view always, which I think is really verbose in cases where a replacement snippet is a "superset" of the snippet that is being replaced.
Consider:
```
LL - Self::Baz: Clone,
LL + Self::Baz: Clone, T: std::clone::Clone
```
In this code, we suggest replacing `", "` with `", T: std::clone::Clone"`. This is a consequence of how the snippet is constructed. I believe that since the string that is being replaced is a subset of the replacement string, it's not providing much value to present this as a diff. Users should be able to clearly understand what's being suggested here using the `~` underline view we've been suggesting for some time now.
Given that this affects ~100 tests out of the ~1000 UI tests affected, I expect this to be a pretty meaningful improvement of the fallout of #127541.
---
In the last commit, this PR also "trims" replacement parts so that they are turned into their purely additive subset, if possible. See the diff for what this means.
---
r? estebank
|
|
Set both `nuw` and `nsw` in slice size calculation
There's an old note in the code to do this, and now that [LLVM-C has an API for it](https://github.com/llvm/llvm-project/blob/f0b8ff12519270adcfef93410abff76ab073476a/llvm/include/llvm-c/Core.h#L4403-L4408), we might as well. And it's been there since what looks like LLVM 17 https://github.com/llvm/llvm-project/commit/de9b6aa341d8951625d62ae3dac8670ebb3eb006 so doesn't even need to be conditional.
(There's other places, like `RawVecInner` or `Layout`, that might want to do things like this too, but I'll leave those for a future PR.)
|
|
|
|
|
|
This matches the HIR changes in #134228, which introduced `PatExpr` to hold the
subset of "expressions" that can appear in a pattern.
|
|
|
|
`transmute` should also assume non-null pointers
Previously it only did integer-ABI things, but this way it does data pointers too. That gives more information in general to the backend, and allows slightly simplifying one of the helpers in slice iterators.
|
|
|
|
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #135439 (Make `-O` mean `OptLevel::Aggressive`)
- #136460 (Simplify `rustc_span` `analyze_source_file`)
- #136904 (add `IntoBounds` trait)
- #136908 ([AIX] expect `EINVAL` for `pthread_mutex_destroy`)
- #136924 (Add profiling of bootstrap commands using Chrome events)
- #136951 (Use the right binder for rebinding `PolyTraitRef`)
- #136981 (ci: switch loongarch jobs to free runners)
- #136992 (Update backtrace)
- #136993 ([cg_llvm] Remove dead error message)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
[cg_llvm] Remove dead error message
Part of #135502
Discovered a dead error message in rustc_codegen_llvm, so removing it.
r? ``@Zalathar``
|
|
Use the right binder for rebinding `PolyTraitRef`
Fixes #136940
I committed a slightly different test which still demonstrates the issue.
|
|
Simplify `rustc_span` `analyze_source_file`
Simplifies the logic to what the code *actually* does, which is to just record newlines and multibyte characters. Checking for other ASCII control characters is unnecessary because the generic fallback doesn't do anything for those cases.
Also uses a simpler (and more efficient) means of iterating the set bits of the mask.
|
|
There's an old note in the code to do this, and now that LLVM-C has an API for it, we might as well.
|
|
Because it's only used in `rustc_mir_transform`. (Presumably it is
currently in `rustc_middle` because lots of other MIR-related stuff is,
but that's not a hard requirement.) And because `rustc_middle` is huge
and it's always good to make it smaller.
|
|
`rustc_mir_dataflow/src/elaborate_drops.rs` contains some infrastructure
used by a few MIR passes: the `elaborate_drop` function, the
`DropElaborator` trait, etc.
`rustc_mir_transform/src/elaborate_drops.rs` (same file name, different
crate) contains the `ElaborateDrops` pass. It relies on a lot of the
infrastructure from `rustc_mir_dataflow/src/elaborate_drops.rs`.
It turns out that the drop infrastructure is only used in
`rustc_mir_transform`, so this commit moves it there. (The only
exception is the small `DropFlagState` type, which is moved to the
existing `rustc_mir_dataflow/src/drop_flag_effects.rs`.) The file is
renamed from `rustc_mir_dataflow/src/elaborate_drops.rs` to
`rustc_mir_transform/src/elaborate_drop.rs` (with no trailing `s`)
because (a) the `elaborate_drop` function is the most important export,
and (b) `rustc_mir_transform/src/elaborate_drops.rs` already exists.
All the infrastructure pieces that used to be `pub` are now
`pub(crate)`, because they are now only used within
`rustc_mir_transform`.
|
|
`ErrorConstraintInfo`
`fr_is_local` was fully unused, and `outlived_fr_is_local` was used once
|
|
|
|
coverage: Eliminate more counters by giving them to unreachable nodes
When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero.
Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed.
This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
|
|
eagerly prove WF when resolving fully qualified paths
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/161.
This hopefully shouldn't impact perf. I do think we need to deal with at least part of the fallout here, opening for vibes.
r? ``@compiler-errors``
|
|
debuginfo: Set bitwidth appropriately in enum variant tags
Previously, we unconditionally set the bitwidth to 128-bits, the largest an enum would possibly be. Then, LLVM would cut down the constant by chopping off leading zeroes before emitting the DWARF. LLVM only supported 64-bit enumerators, so this would also have occasionally resulted in truncated data.
LLVM added support for 128-bit enumerators in llvm/llvm-project#125578
That patchset trusts the constant to describe how wide the variant tag is, so the high 64-bits of zeros are considered potentially load-bearing.
As a result, we went from emitting tags that looked like:
DW_AT_discr_value (0xfe)
(because `dwarf::BestForm` selected `data1`)
to emitting tags that looked like:
DW_AT_discr_value (<0x10> fe ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 )
This makes the `DW_AT_discr_value` encode at the bitwidth of the tag, which:
1. Is probably closer to our intentions in terms of describing the data.
2. Doesn't invoke the 128-bit support which may not be supported by all debuggers / downstream tools.
3. Will result in smaller debug information.
|
