| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
coverage: Allow each coverage statement to have multiple code regions
The original implementation of coverage instrumentation was built around the assumption that a coverage counter/expression would be associated with *up to one* code region. When it was discovered that *multiple* regions would sometimes need to share a counter, a workaround was found: for the remaining regions, the instrumentor would create a fresh expression that adds zero to the existing counter/expression.
That got the job done, but resulted in some awkward code, and produces unnecessarily complicated coverage maps in the final binary.
---
This PR removes that tension by changing `StatementKind::Coverage`'s code region field from `Option<CodeRegion>` to `Vec<CodeRegion>`.
The changes on the codegen side are fairly straightforward. As long as each `CoverageKind::Counter` only injects one `llvm.instrprof.increment`, the rest of coverage codegen is happy to handle multiple regions mapped to the same counter/expression, with only minor option-to-vec adjustments.
On the instrumentor/mir-transform side, we can get rid of the code that creates extra (x + 0) expressions. Instead we gather all of the code regions associated with a single BCB, and inject them all into one coverage statement.
---
There are several patches here but they can be divided in to three phases:
- Preparatory work
- Actually switching over to multiple regions per coverage statement
- Cleaning up
So viewing the patches individually may be easier.
|
|
r=compiler-errors
non_lifetime_binders: fix ICE in lint opaque-hidden-inferred-bound
Opaque types like `impl for<T> Trait<T>` would previously lead to an ICE.
r? `@compiler-errors`
|
|
Factor out common token generation in `fluent_messages`.
The failure and success cases are similar enough that they can share code.
r? `@davidtwco`
|
|
Fix broken links
The previous address is no longer available, replace it with the latest available one.
|
|
a small wf and clause cleanup
- remove `Clause::from_projection_clause`, instead use `ToPredicate`
- change `predicate_obligations` to directly take a `Clause`
- remove some unnecessary `&`
- use clause in `min_specialization` checks where easily applicable
|
|
Suggest `pin!()` instead of `Pin::new()` when appropriate
When encountering a type that needs to be pinned but that is `!Unpin`, suggest using the `pin!()` macro.
Fix #57994.
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #115863 (Add check_unused_messages in tidy)
- #116210 (Ensure that `~const` trait bounds on associated functions are in const traits or impls)
- #116358 (Rename both of the `Match` relations)
- #116371 (Remove unused features from `rustc_llvm`.)
- #116374 (Print normalized ty)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Print normalized ty
Inside `mir_assign_valid_types` we are comparing normalized type of `mir_place` but in debug message we are not printing the normalized value, this changes that.
|
|
Remove unused features from `rustc_llvm`.
r? `@bjorn3`
|
|
Rename both of the `Match` relations
Both of these names kinda were ambiguous.
r? lcnr
|
|
Ensure that `~const` trait bounds on associated functions are in const traits or impls
Zulip discussion: https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/How.20to.2Fshould.20I.20try.20to.20pinpoint.20ICEs.20related.20to.20effects.3F
|
|
Add check_unused_messages in tidy
From https://github.com/rust-lang/rust/pull/115728#issuecomment-1715490553
The check is not 100% accurate, I guess it's enough for now.
|
|
Make subtyping explicit in MIR
This adds new mir-opt that pushes new `ProjectionElem` called `ProjectionElem::Subtype(T)` to `Rvalue` of a subtyped assignment so we can unsoundness issues like https://github.com/rust-lang/rust/issues/107205
Addresses https://github.com/rust-lang/rust/issues/112651
r? `@lcnr`
|
|
|
|
r=wesleywiser
Don't suggest nonsense suggestions for unconstrained type vars in `note_source_of_type_mismatch_constraint`
The way we do type inference for suggestions in `note_source_of_type_mismatch_constraint` is a bit strange. We compute the "ideal" method signature, which takes the receiver that we *want* and uses it to compute the types of the arguments that would have given us that receiver via type inference, and use *that* to suggest how to change an argument to make sure our receiver type is inferred correctly.
The problem is that sometimes we have totally unconstrained arguments (well, they're constrained by things outside of the type checker per se, like associated types), and therefore type suggestions are happy to coerce anything to that unconstrained argument. This leads to bogus suggestions, like #116155. This is partly due to above, and partly due to the fact that `emit_type_mismatch_suggestions` doesn't double check that its suggestions are actually compatible with the program other than trying to satisfy the type mismatch.
This adds a hack to make sure that at least the types are fully constrained, but I guess I could also rip out this logic altogether. There would be some sad diagnostics regressions though, such as `tests/ui/type/type-check/point-at-inference-4.rs`.
Fixes #116155
|
|
For a single impl candidate, try to unify it with error trait ref
This allows us to point out an exact type mismatch when there's only one applicable impl.
cc `@asquared31415`
r? `@estebank`
|
|
|
|
When these methods were originally written, I wasn't aware that
`newtype_index!` already supports addition with ordinary numbers, without
needing to unwrap and re-wrap.
|
|
Now that coverage statements can have multiple code regions attached to them,
this code is never used.
|
|
If a BCB has more than one code region, those extra regions can now all be
stored in the same coverage statement, instead of being stored in additional
statements.
|
|
This makes it possible for a `StatementKind::Coverage` to hold more than one
code region, but that capability is not yet used.
|
|
The concrete type `CoverageSpan` is no longer used outside of the `spans`
module.
This is a separate patch to avoid noise in the preceding patch that actually
encapsulates coverage spans.
|
|
By encapsulating the coverage spans in a struct, we can change the internal
representation without disturbing existing call sites. This will be useful for
grouping coverage spans by BCB.
This patch includes some changes that were originally in #115912, which avoid
the need for a particular test to deal with coverage spans at all.
(Comments/logs referring to `CoverageSpan` are updated in a subsequent patch.)
|
|
There is no need to include a dummy counter reference in the coverage mappings
for an unused function.
|
|
|
|
|
|
Rebased: Mark drop calls in landing pads cold instead of noinline
I noticed that certain inlining optimizations were missing while staring at some compiled code output. I'd like to see this relanded, so I rebased the PR from `@erikdesjardins` (PR #94823).
This PR reapplies https://github.com/rust-lang/rust/pull/92419, which was reverted in https://github.com/rust-lang/rust/pull/94402 due to https://github.com/rust-lang/rust/issues/94390.
Fixes https://github.com/rust-lang/rust/issues/46515, fixes https://github.com/rust-lang/rust/issues/87055.
Update: fixes #97217.
|
|
note_source_of_type_mismatch_constraint
|
|
|
|
|
|
|
|
|
|
|
|
Replace `HashMap` with `IndexMap` in pattern binding resolve
fixes https://github.com/rust-lang/rust/pull/114332#discussion_r1284189179
|
|
It will be iterated over, so we should avoid using `HashMap`.
|
|
`skip_binder` to `instantiate_identity`
|
|
Some small cleanups in `rustc_abi`
Minor things I found while looking at this crate's code.
r? `@the8472`
|
|
|
|
|
|
Co-authored-by: Max Fan <git@max.fan>
Co-authored-by: Nikita Popov <npopov@redhat.com>
|
|
bootstrap major change detection implementation
The use of `changelog-seen` and `bootstrap/CHANGELOG.md` has not been functional in any way for many years. We often do major/breaking changes but never update the changelog file or the `changelog-seen`. This is an alternative method for tracking major or breaking changes and informing developers when such changes occur.
Example output when bootstrap detects a major change:
|
|
Compiling any part of the compiler will almost certainly require
Nightly.
|
|
The failure and success cases are similar enough that they can share
code.
|
|
By making every `alt_foo` exactly match a `foo`.
|
|
Cleanup number handling in match exhaustiveness
Doing a little bit of cleanup; handling number constants was somewhat messy. In particular, this:
- evals float consts once instead of repetitively
- reduces `Constructor` from 88 bytes to 56 (`mir::Const` is big!)
The `fast_try_eval_bits` function was mostly constructed from inlining existing code but I don't fully understand it; I don't follow how consts work and are evaluated very well.
|
|
|
|
Factor out duplicated `entry_point_type` functions
A small but nice cleanup.
|
|
resolve: skip underscore character during candidate lookup
Fixes #116164
In use statement, an underscore is merely a placeholder symbol and does not bind to any name. Therefore, it can be safely ignored.
|
