| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Add `debug_assert_nounwind` and convert `assert_unsafe_precondition`
`assert_unsafe_precondition` checks non-CTFE-evaluable conditions in runtime and performs no-op in compile time, while many of its current usage can be checked during const eval.
|
|
Rollup of 7 pull requests
Successful merges:
- #117651 (coverage: Simplify building coverage expressions based on sums)
- #117968 (Stabilize `ptr::addr_eq`)
- #118158 (Reduce fluent boilerplate)
- #118201 (Miscellaneous `ObligationCauseCode` cleanups)
- #118288 (Use `is_{some,ok}_and` more in the compiler)
- #118289 (`is_{some,ok}_and` for rustdoc)
- #118290 (Don't ICE when encountering placeholders in implied bounds computation)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Rewrite exhaustiveness in one pass
This is at least my 4th attempt at this in as many years x) Previous attempts were all too complicated or too slow. But we're finally here!
The previous version of the exhaustiveness algorithm computed reachability for each arm then exhaustiveness of the whole match. Since each of these steps does roughly the same things, this rewrites the algorithm to do them all in one go. I also think this makes things much simpler.
I also rewrote the documentation of the algorithm in depth. Hopefully it's up-to-date and easier to follow now. Plz comment if anything's unclear.
r? `@oli-obk` I think you're one of the rare other people to understand the exhaustiveness algorithm?
cc `@varkor` I know you're not active anymore, but if you feel like having a look you might enjoy this :D
Fixes https://github.com/rust-lang/rust/issues/79307
|
|
|
|
Don't ICE when encountering placeholders in implied bounds computation
I *could* fix this the right way, though I don't really want to think about the implications of the change. This should have minimal side-effects.
r? `@aliemjay`
Fixes #118286
|
|
r=compiler-errors
Reduce fluent boilerplate
Best reviewed one commit at a time.
r? `@davidtwco`
|
|
coverage: Simplify building coverage expressions based on sums
This is a combination of some interlinked changes to the code that creates coverage counters/expressions for nodes and edges in the coverage graph:
- Some preparatory cleanups in `MakeBcbCounters::make_branch_counters`
- Use `BcbCounter` (instead of `CovTerm`) when building coverage expressions
- This makes it easier to introduce a fold for building sums
- Simplify the creation of coverage expressions based on sums, by having `Iterator::fold` do much of the work
- Get rid of the awkward `BcbBranch` enum, and replace it with graph edges represented as `(from_bcb, to_bcb)`
- This further simplifies the body of the fold
|
|
Currently we always do this:
```
use rustc_fluent_macro::fluent_messages;
...
fluent_messages! { "./example.ftl" }
```
But there is no need, we can just do this everywhere:
```
rustc_fluent_macro::fluent_messages! { "./example.ftl" }
```
which is shorter.
|
|
The `fluent_messages!` macro produces uses of
`crate::{D,Subd}iagnosticMessage`, which means that every crate using
the macro must have this import:
```
use rustc_errors::{DiagnosticMessage, SubdiagnosticMessage};
```
This commit changes the macro to instead use
`rustc_errors::{D,Subd}iagnosticMessage`, which avoids the need for the
imports.
|
|
Rollup of 6 pull requests
Successful merges:
- #116446 (Yeet `mir::Const::from_anon_const`)
- #117871 (remove unused pub fns)
- #118017 (rustc_lint: address latent TODO)
- #118199 (Remove `HirId` from `QPath::LangItem`)
- #118272 (resolve: Avoid clones of `MacroData`)
- #118291 (rustdoc-search: clean up some DOM code)
Failed merges:
- #118201 (Miscellaneous `ObligationCauseCode` cleanups)
- #118256 (rustc: `hir().local_def_id_to_hir_id()` -> `tcx.local_def_id_to_hir_id()` cleanup)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
the unadjusted ABI needs to pass aggregates by-value
Fixes https://github.com/rust-lang/rust/issues/118124, a regression introduced in https://github.com/rust-lang/rust/pull/117500
|
|
Rollup of 9 pull requests
Successful merges:
- #118220 (general improvements/fixes on bootstrap)
- #118251 (rustdoc-search: avoid infinite where clause unbox)
- #118253 (Replace `option.map(cond) == Some(true)` with `option.is_some_and(cond)`)
- #118255 (Request that rust-analyzer changes are sent upstream first if possible)
- #118259 (Move EagerResolution to rustc_infer::infer::resolve)
- #118262 (Relate Inherent Associated Types using eq)
- #118266 (Move stuff around on `stable_mir` and `rustc_smir` crate)
- #118271 (Separate `NaN`/`Inf` floats with `_`)
- #118274 (Fix smir's `Ty::Ref` pretty printing)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
rustdoc-search: avoid infinite where clause unbox
Fixes #118242
|
|
Validate there are no critical call edges in optimized MIR
|
|
In some cases we need to prepare a coverage expression that is the sum of an
arbitrary number of other terms. This patch simplifies the code paths that
build those sums.
This causes some churn in the mappings, because the previous code was building
its sums in a somewhat idiosyncratic order.
|
|
Fixes error count display is different when there's only one error left
Supersedes #114759
### What did I do?
I did the small change in `rustc_errors` by hand. Then I did the other changes in `/compiler` by hand, those were just find replace on `*.rs` in the workspace. The changes in run-make are find replace for `run-make` in the workspace.
All other changes are blessed using `x test TEST --bless`. I blessed the tests that were blessed in #114759.
### how to review this nightmare
ping bors with an `r+`. You should check that my logic is sound and maybe quickly scroll through the diff, but fully verifying it seems fairly hard to impossible. I did my best to do this correctly.
Thank you `@adrianEffe` for bringing this up and your initial implementation.
cc `@flip1995,` you said you want to do a subtree sync asap
cc `@RalfJung` maybe you want to do a quick subtree sync afterwards as well for Miri
r? `@WaffleLapkin`
|
|
We have to ignore some tests in stage1.
|
|
|
|
Co-authored-by: Adrian <adrian.iosdev@gmail.com>
|
|
Co-authored-by: Adrian <adrian.iosdev@gmail.com>
|
|
Co-authored-by: Adrian <adrian.iosdev@gmail.com>
|
|
Fixes #118242
|
|
Rollup of 7 pull requests
Successful merges:
- #118187 (Recompile LLVM when it changes in the git sources)
- #118210 (intercrate ambiguity causes: ignore candidates which don't apply)
- #118215 (Add common trait for crate definitions)
- #118238 (memcpy assumptions: update GCC link)
- #118243 (EvalCtxt::commit_if_ok don't inherit nested goals)
- #118245 (Add `Span` to `TraitBoundModifier`)
- #118246 (Remove a hack for effects)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add `Span` to `TraitBoundModifier`
This improves diagnostics for the message "`~const` is not allowed here", and also fixes the span that we use when desugaring `~const Tr` into `Tr<host>` in effects desugaring.
|
|
Add common trait for crate definitions
In stable mir, we specialize DefId, however some functionality is the same for every definition, such as def paths, and getting their crate. Use a trait to implement those.
|
|
r=compiler-errors
intercrate ambiguity causes: ignore candidates which don't apply
r? `@compiler-errors`
|
|
feat: make `let_binding_suggestion` more reasonable
This is my first PR for rustc, which trying to fix https://github.com/rust-lang/rust/issues/117894, I am not familiar with some internal api so maybe some modification here isn't the way to go, appreciated for any review suggestion.
|
|
|
|
Sort unstable items last in rustdoc, instead of first
As far as I can tell, this is a bug introduced inadvertently by https://github.com/rust-lang/rust/pull/77817 in Rust 1.49. Older toolchains used to sort unstable items last.
Notice how in the code before that PR, `(Unstable, Stable) => return Ordering::Greater` in src/librustdoc/html/render/mod.rs. Whereas after that PR, `(Unstable, Stable) => return Ordering::Less`.
Compare https://doc.rust-lang.org/1.48.0/std/marker/index.html vs https://doc.rust-lang.org/1.49.0/std/marker/index.html.
|
|
rustdoc: rename `issue-\d+.rs` tests to have meaningful names (part 4)
Follow up
* https://github.com/rust-lang/rust/pull/116214
* https://github.com/rust-lang/rust/pull/116432
* https://github.com/rust-lang/rust/pull/116824
|
|
|
|
|
|
|
|
|
|
Don't print "private fields" on empty tuple structs
Closes #118180.
While working on this I also noticed that empty struct variants are also rendered rather awkwardly. I'll make another issue for that, since I don't know what the correct rendering would be.
|
|
Test for presence rather than absence
Remove redundant tests
Issues in those parts will likely be caught by other parts of the test suite.
|
|
In accordance with the [process](https://github.com/rust-lang/lang-team/blob/master/src/how_to/experiment.md).
Detailed description of the feature can be found in the RFC repo - https://github.com/rust-lang/rfcs/pull/3530.
|
|
|
|
|
|
Rework supertrait lint once again
I accidentally pushed the wrong commits because I totally didn't check I was on the right computer when updating #118026.
Sorry, this should address all the nits in #118026.
r? lcnr
|
|
improve tool-only help for multiple `#[default]` variants
When defining an enum with multiple `#[default]` variants, we emit a tool-only suggestion for every `#[default]`ed variant to remove all other `#[default]`s. This PR improves the suggestion to correctly handle the cases where one variant has multiple `#[default]`s and where different `#[default]`s have the same span due to macro expansions.
fixes https://github.com/rust-lang/rust/issues/118119
|
|
When failing to import `core`, suggest `std`
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #118012 (Add support for global allocation in smir)
- #118013 (Enable Rust to use the EHCont security feature of Windows)
- #118100 (Enable profiler in dist-powerpc64-linux)
- #118142 (Tighten up link attributes for llvm-wrapper bindings)
- #118147 (Fix some unnecessary casts)
- #118161 (Allow defining opaques in `check_coroutine_obligations`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Allow defining opaques in `check_coroutine_obligations`
In the new trait solver, when an obligation stalls on an unresolved coroutine witness, we will stash away the *root* obligation, even if the stalled obligation is only a distant descendent of the root obligation, since the new solver is purely recursive.
This means that we may need to reprocess alias-relate obligations (and others) which may define opaque types in the new solver. Currently, we use the coroutine's def id as the defining anchor in `check_coroutine_obligations`, which will allow defining no opaque types, resulting in errors like:
```
error[E0271]: type mismatch resolving `{coroutine@<source>:6:5: 6:17} <: impl Clone`
--> <source>:6:5
|
6 | / move |_: ()| {
7 | | let () = yield ();
8 | | }
| |_____^ types differ
```
So this PR fixes the defining anchor and does the same trick as `check_opaque_well_formed`, where we manually compare opaques that were defined against their hidden types to make sure they weren't defined differently when processing these stalled coroutine obligations.
r? `@lcnr` cc `@cjgillot`
|
|
Enable Rust to use the EHCont security feature of Windows
In the future Windows will enable Control-flow Enforcement Technology (CET aka Shadow Stacks). To protect the path where the context is updated during exception handling, the binary is required to enumerate valid unwind entrypoints in a dedicated section which is validated when the context is being set during exception handling.
The required support for EHCONT Guard has already been merged into LLVM, long ago. This change simply adds the Rust codegen option to enable it.
Relevant LLVM change: https://reviews.llvm.org/D40223
This also adds a new `ehcont-guard` option to the bootstrap config which enables EHCont Guard when building std.
We at Microsoft have been using this feature for a significant period of time; we are confident that the LLVM feature, when enabled, generates well-formed code.
We currently enable EHCONT using a codegen feature, but I'm certainly open to refactoring this to be a target feature instead, or to use any appropriate mechanism to enable it.
|
