| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Update triagebot.toml: celinval vacation is over
I'm also removing myself from the MIR syntax changes notifications.
|
|
[generic_assert] Constify methods used by the formatting system
cc #44838
Starts the "constification" of all the elements required to allow the execution of the formatting system in constant environments.
```rust
const _: () = { panic!("{:?}", 1i32); };
```
Further stuff is blocked by #133999.
|
|
mark deprecated option as deprecated in rustc_session to remove copypasta and small refactor
This marks deprecated options as deprecated via flag in options table in rustc_session, which removes copypasted deprecation text from rustc_driver_impl.
This also adds warning for deprecated `-C ar` option, which didn't emitted any warnings before.
Makes `inline_threshold` `[UNTRACKED]`, as it do nothing.
Adds few tests.
See individual commits.
|
|
rustdoc: Fix mismatched capitalization in sidebar
Previously, the main content used "Aliased Type", while the sidebar said "Aliased type". Now, they both say "Aliased Type", which is the more common capitalization in Rustdoc.
See the following link for an example.
https://doc.rust-lang.org/1.83.0/std/io/type.Result.html
|
|
r=lqd,jieyouxu
Suggest to replace tuple constructor through projection
See the code example. when `Self::Assoc` normalizes to a struct that has a tuple constructor, you cannot construct the type via `Self::Assoc(field, field)`. Instead, suggest to replace it with the correct named struct.
Fixes #120871
|
|
Don't ice on bad transmute in typeck in new solver
Old trait solver ends up getting its infcx tainted because we try to normalize the type, but the new trait solver doesn't. This means we try to compute the stalled transmute obligations, which tries to normalize a type an ICEs. Let's make this a delayed bug.
r? lcnr
|
|
Release notes for 1.84.0
cc ``@rust-lang/release`` r? ``@Mark-Simulacrum``
|
|
Improve diagnostics for `HostEffectPredicate` in the new solver
Adds derived cause for host effect predicates. Some diagnostics regress, but that's connected to the fact that our predicate visitor doesn't play well with aliases just yet.
|
|
Add support for wasm exception handling to Emscripten target
This is a draft because we need some additional setting for the Emscripten target to select between the old exception handling and the new exception handling. I don't know how to add a setting like that, would appreciate advice from Rust folks. We could maybe choose to use the new exception handling if `Ctarget-feature=+exception-handling` is passed? I tried this but I get errors from llvm so I'm not doing it right.
|
|
Rollup of 7 pull requests
Successful merges:
- #134742 (Use `PostBorrowckAnalysis` in `check_coroutine_obligations`)
- #134771 (Report correct `SelectionError` for `ConstArgHasType` in new solver fulfill)
- #134951 (Suppress host effect predicates if underlying trait doesn't hold)
- #135097 (bootstrap: Consolidate coverage test suite steps into a single step)
- #135146 (Don't enable anyhow's `backtrace` feature in opt-dist)
- #135153 (chore: remove redundant words in comment)
- #135157 (Move the has_errors check in rustdoc back to after TyCtxt is created)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Previously, the main content used "Aliased Type", while the sidebar said
"Aliased type". Now, they both say "Aliased Type", which is the more common
capitalization in Rustdoc.
See the following link for an example.
https://doc.rust-lang.org/1.83.0/std/io/type.Result.html
|
|
r=jieyouxu,GuillaumeGomez
Move the has_errors check in rustdoc back to after TyCtxt is created
This was accidentally moved before TyCtxt creation by https://github.com/rust-lang/rust/pull/134302.
|
|
chore: remove redundant words in comment
|
|
Don't enable anyhow's `backtrace` feature in opt-dist
As of the stabilization of `std::backtrace` in Rust 1.65, this package flag has no effect other than to enable an unused dependency on the `backtrace` crate.
(See <https://github.com/dtolnay/anyhow/blob/af0937ef72fbaf9784a6c991e029738728d025e2/Cargo.toml#L18-L23>.)
While the presence of this feature in opt-dist doesn't cause other tools (which use anyhow) to actually *build* backtrace, it does affect the global crate graph used for dependency version resolution. After removing this feature, we can use `cargo tree --invert --package backtrace` to see that the only remaining reverse-dependency of backtrace is `color-eyre`, which is used by `ui_test`.
|
|
bootstrap: Consolidate coverage test suite steps into a single step
Now that I have more understanding of bootstrap steps, and a renewed distaste for unnecessary macros, I have managed to express the subtleties of the `tests/coverage` test suite in a single step defined in ordinary code, with no need for helper macros.
Deciding which modes to run is still a bit clunky due to limitations in existing ShouldRun/PathSet APIs, but I think it's a net improvement over having to declare several different steps to handle the suite path and aliases.
The interaction with `--skip` isn't as nice as I'd like, but all of the known limitations are limitations that already existed in the previous implementation.
One minor change is that by default compiletest is now invoked in `coverage-run` mode even when cross-compiling. However, in that situation compiletest still knows that it should skip all of the individual coverage-run tests.
r? jieyouxu (or reassign)
|
|
Suppress host effect predicates if underlying trait doesn't hold
Don't report two errors for when the (`HostEffectPredicate`) `T: const Trait` isn't implemented because (`TraitPredicate`) `T: Trait` doesn't even hold.
|
|
Report correct `SelectionError` for `ConstArgHasType` in new solver fulfill
r? ``@BoxyUwU``
|
|
Use `PostBorrowckAnalysis` in `check_coroutine_obligations`
This currently errors with:
```
error: concrete type differs from previous defining opaque type use
--> tests/ui/coroutine/issue-52304.rs:10:21
|
10 | pub fn example() -> impl Coroutine {
| ^^^^^^^^^^^^^^ expected `{example::{closure#0} upvar_tys=() resume_ty=() yield_ty=&'{erased} i32 return_ty=() witness={example::{closure#0}}}`, got `{example::{closure#0} upvar_tys=() resume_ty=() yield_ty=&'static i32 return_ty=() witness={example::{closure#0}}}`
|
= note: previous use here
```
This is because we end up redefining the opaque in `check_coroutine_obligations` but with the `yield_ty = &'erased i32` from hir typeck, which causes the *equality* check for opaques to fail.
The coroutine obligtions in question (when `-Znext-solver` is enabled) are:
```
Binder { value: TraitPredicate(<Opaque(DefId(0:5 ~ issue_52304[4c6d]::example::{opaque#0}), []) as std::marker::Sized>, polarity:Positive), bound_vars: [] }
Binder { value: AliasRelate(Term::Ty(Alias(Opaque, AliasTy { args: [], def_id: DefId(0:5 ~ issue_52304[4c6d]::example::{opaque#0}), .. })), Equate, Term::Ty(Coroutine(DefId(0:6 ~ issue_52304[4c6d]::example::{closure#0}), [(), (), &'{erased} i32, (), CoroutineWitness(DefId(0:6 ~ issue_52304[4c6d]::example::{closure#0}), []), ()]))), bound_vars: [] }
Binder { value: AliasRelate(Term::Ty(Coroutine(DefId(0:6 ~ issue_52304[4c6d]::example::{closure#0}), [(), (), &'{erased} i32, (), CoroutineWitness(DefId(0:6 ~ issue_52304[4c6d]::example::{closure#0}), []), ()])), Subtype, Term::Ty(Alias(Opaque, AliasTy { args: [], def_id: DefId(0:5 ~ issue_52304[4c6d]::example::{opaque#0}), .. }))), bound_vars: [] }
```
Ignoring the fact that we end up stalling some really dumb obligations here (lol), I think it makes more sense for us to be using post borrowck analysis for this check anyways.
r? lcnr
|
|
I'm also removing myself from the MIR syntax changes notifications.
|
|
|
|
|
|
|
|
|
|
|
|
inline_threshold mark deprecated
no-stack-check
print deprecation message for -Car too
inline_threshold deprecated and do nothing: make in untracked
make OptionDesc struct from tuple
|
|
|
|
Merge the intrinsic and user tests for `select_unpredictable`
[1] mentions that having a single test with `-Zmerge-functions=disabled` is preferable to having two separate tests. Apply that to the new `select_unpredictable` test here.
[1]: https://github.com/rust-lang/rust/pull/133964#issuecomment-2569693325
|
|
|
|
Gated behind an unstable `-Z emscripten-wasm-eh` flag
|
|
Rollup of 6 pull requests
Successful merges:
- #135111 (Add doc aliases for `libm` and IEEE names)
- #135129 (triagebot: label `src/doc/rustc-dev-guide` changes with `A-rustc-dev-guide`)
- #135132 (dev guide ping group and set adhoc reviewers to compiler)
- #135145 (Mention `unnameable_types` in `unreachable_pub` documentation.)
- #135147 (A few borrowck tweaks to improve 2024 edition migration lints)
- #135150 (move footnote to ordinary comment)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Signed-off-by: crystalstall <crystalruby@qq.com>
|
|
move footnote to ordinary comment
cc #135057
|
|
A few borrowck tweaks to improve 2024 edition migration lints
See first two commits' changes to test outputs. Test coverage in this area is kinda weak, but I think it affects more cases than this (like the craters that will begin to trigger the `tail_expr_drop_order` tests in #134523).
Third commit is a drive-by change that removes a deref hack from `UseSpans` which doesn't really improve diagnostics much.
|
|
Mention `unnameable_types` in `unreachable_pub` documentation.
This link makes sense because someone who wishes to avoid unusable `pub` is likely, but not guaranteed, to be interested in avoiding unnameable types.
Also fixed some grammar problems I noticed in the area.
Fixes #116604.
r? Urgau
|
|
dev guide ping group and set adhoc reviewers to compiler
r? ``@jieyouxu`` ``@Kobzol``
I added you both to the `cc` list since you're both also on the list of owners for `src/doc/rustc-dev-guide`
|
|
triagebot: label `src/doc/rustc-dev-guide` changes with `A-rustc-dev-guide`
Probably should also create a dev-guide reviewer pool for this repo 🤔
r? ``@Kobzol``
|
|
Add doc aliases for `libm` and IEEE names
Searching "fma" in the Rust documentation returns results for `intrinsics::fma*`, but does not point to the user-facing `mul_add`. Add aliases for `fma*` and the IEEE operation name `fusedMultiplyAdd`. Add the IEEE name to `sqrt` as well, `squareRoot`.
|
|
|
|
add m68k-unknown-none-elf target
r? `@workingjubilee`
The existing `m68k-unknown-linux-gnu` target builds `std` by default, requires atomics, and has a base cpu with an fpu. A smaller/more embedded target is desirable both to have a baseline target for the ISA, as well to make debugging easier for working on the llvm backend. Currently this target is using the `M68010` as the minimum CPU due, but as missing features are merged into the `M68k` llvm backend I am hoping to lower this further.
I have been able to build very small crates using a toolchain built against this target (together with a later version of `object`) using the configuration described in the target platform-support documentation, although getting anything of substantial complexity to build quickly hits errors in the llvm backend
|
|
It's not really necessary
|
|
|
|
|
|
Rollup of 3 pull requests
Successful merges:
- #135115 (cg_llvm: Use constants for DWARF opcodes, instead of FFI calls)
- #135118 (Clarified the documentation on `core::iter::from_fn` and `core::iter::successors`)
- #135121 (Mark `slice::reverse` unstably const)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
As of the stabilization of `std::backtrace` in Rust 1.65, this package flag has
no effect other than to enable an unused dependency on the `backtrace` crate.
|
|
This link makes sense because someone who wishes to avoid unusable `pub`
is likely, but not guaranteed, to be interested in avoiding unnameable
types.
Also fixed some grammar problems I noticed in the area.
Fixes #116604.
|
|
|
|
Mark `slice::reverse` unstably const
Tracking issue #135120
This is unblocked by the stabilization of `const_swap`
|
|
Clarified the documentation on `core::iter::from_fn` and `core::iter::successors`
This PR clarifies the closure requirements for `core::iter::from_fn` and `core::iter::successors`.
`std::iter::successors` in particular is a bit difficult to understand if you are not already familiar with the signature of [`checked_mul`](https://docs.rs/num/latest/num/trait.CheckedMul.html) used in the example.
See https://github.com/rust-lang/rust/issues/135087
|
|
cg_llvm: Use constants for DWARF opcodes, instead of FFI calls
Split off from #134009 to incorporate feedback from https://github.com/rust-lang/rust/pull/134009#discussion_r1903133906.
Most of the constant values now come from gimli, which is already a compiler dependency.
I noticed that `DW_OP_LLVM_fragment` is an LLVM detail that is not defined by DWARF and could hypothetically change, so I added a static assertion on the C++ side to detect that if it ever happens.
r? workingjubilee
|
|
Add a notion of "some ABIs require certain target features"
I think I finally found the right shape for the data and checks that I recently added in https://github.com/rust-lang/rust/pull/133099, https://github.com/rust-lang/rust/pull/133417, https://github.com/rust-lang/rust/pull/134337: we have a notion of "this ABI requires the following list of target features, and it is incompatible with the following list of target features". Both `-Ctarget-feature` and `#[target_feature]` are updated to ensure we follow the rules of the ABI. This removes all the "toggleability" stuff introduced before, though we do keep the notion of a fully "forbidden" target feature -- this is needed to deal with target features that are actual ABI switches, and hence are needed to even compute the list of required target features.
We always explicitly (un)set all required and in-conflict features, just to avoid potential trouble caused by the default features of whatever the base CPU is. We do this *before* applying `-Ctarget-feature` to maintain backward compatibility; this poses a slight risk of missing some implicit feature dependencies in LLVM but has the advantage of not breaking users that deliberately toggle ABI-relevant target features. They get a warning but the feature does get toggled the way they requested.
For now, our logic supports x86, ARM, and RISC-V (just like the previous logic did). Unsurprisingly, RISC-V is the nicest. ;)
As a side-effect this also (unstably) allows *enabling* `x87` when that is harmless. I used the opportunity to mark SSE2 as required on x86-64, to better match the actual logic in LLVM and because all x86-64 chips do have SSE2. This infrastructure also prepares us for requiring SSE on x86-32 when we want to use that for our ABI (and for float semantics sanity), see https://github.com/rust-lang/rust/issues/133611, but no such change is happening in this PR.
r? `@workingjubilee`
|
