| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fix broken link to Ayu theme in the rustdoc book
Fixes #116977
|
|
Mention the syntax for `use` on `mod foo;` if `foo` doesn't exist
Newcomers might get confused that `mod` is the only way of defining scopes, and that it can be used as if it were `use`.
Fix #69492.
|
|
update the registers of csky target
|
|
Updated README with expandable table of content.
Make it easier to navigate in the rather large README file.
|
|
fix bootstrap paths in triagebot.toml
ref #https://github.com/rust-lang/rust/pull/116881#issuecomment-1769730250
|
|
Initiate the inner usage of `cfg_match` (Compiler)
cc #115585
Dogfood to test the implementation and remove dependencies.
|
|
|
|
coverage: Emit mappings for unused functions without generating stubs
For a while I've been annoyed by the fact that generating coverage maps for unused functions involves generating a stub function at the LLVM level.
As I suspected, generating that stub function isn't actually necessary, as long as we specifically tell LLVM about the symbol names of all the functions that have coverage mappings but weren't codegenned (due to being unused).
---
There is some helper code that gets moved around in the follow-up patches, so look at the first patch to see the most important functional changes.
---
`@rustbot` label +A-code-coverage
|
|
Newcomers might get confused that `mod` is the only way of defining
scopes, and that it can be used as if it were `use`.
Fix #69492.
|
|
|
|
Clippy subtree update
r? `@Manishearth`
|
|
Rollup of 3 pull requests
Successful merges:
- #106601 (Suggest `;` after bare `match` expression E0308)
- #116975 (Move `invalid-llvm-passes` test to `invalid-compile-flags` folder)
- #117019 (fix spans for removing `.await` on `for` expressions)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
fix spans for removing `.await` on `for` expressions
We need to use a span with the outer syntax context of a desugared `for` expression to join it with the `.await` span.
fixes https://github.com/rust-lang/rust/issues/117014
|
|
Move `invalid-llvm-passes` test to `invalid-compile-flags` folder
Nowadays there is an `invalid-compile-flags` folder, thus move this one there.
|
|
Suggest `;` after bare `match` expression E0308
Fix #72634.
|
|
Rustup
r? `@ghost`
changelog: none
|
|
|
|
|
|
|
|
Lint `non_exhaustive_omitted_patterns` by columns
This is a rework of the `non_exhaustive_omitted_patterns` lint to make it more consistent. The intent of the lint is to help consumers of `non_exhaustive` enums ensure they stay up-to-date with all upstream variants. This rewrite fixes two cases we didn't handle well before:
First, because of details of exhaustiveness checking, the following wouldn't lint `Enum::C` as missing:
```rust
match Some(x) {
Some(Enum::A) => {}
Some(Enum::B) => {}
_ => {}
}
```
Second, because of the fundamental workings of exhaustiveness checking, the following would treat the `true` and `false` cases separately and thus lint about missing variants:
```rust
match (true, x) {
(true, Enum::A) => {}
(true, Enum::B) => {}
(false, Enum::C) => {}
_ => {}
}
```
Moreover, it would correctly not lint in the case where the pair is flipped, because of asymmetry in how exhaustiveness checking proceeds.
A drawback is that it no longer makes sense to set the lint level per-arm. This will silently break the lint for current users of it (but it's behind a feature gate so that's ok).
The new approach is now independent of the exhaustiveness algorithm; it's a separate pass that looks at patterns column by column. This is another of the motivations for this: I'm glad to move it out of the algorithm, it was akward there.
This PR is almost identical to https://github.com/rust-lang/rust/pull/111651. cc `@eholk` who reviewed it at the time. Compared to then, I'm more confident this is the right approach.
|
|
Warn missing_enforced_import_renames by default
Similar to https://github.com/rust-lang/rust-clippy/pull/8261 that did the same thing to disallowed_methods & disallowed_types.
This lint is also only triggered if import renames are defined in the `clippy.toml` file.
changelog: Moved [`missing_enforced_import_renames`] to `style` (Now warn-by-default)
[#11539](https://github.com/rust-lang/rust-clippy/pull/11539)
|
|
Rollup of 8 pull requests
Successful merges:
- #114521 (std: freebsd build update.)
- #116911 (Suggest relaxing implicit `type Assoc: Sized;` bound)
- #116917 (coverage: Simplify the injection of coverage statements)
- #116961 (Typo suggestion to change bindings with leading underscore)
- #116964 (Add stable Instance::body() and RustcInternal trait)
- #116974 (coverage: Fix inconsistent handling of function signature spans)
- #116990 (Mention `into_iter` on borrow errors suggestions when appropriate)
- #116995 (Point at assoc fn definition on type param divergence)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Point at assoc fn definition on type param divergence
When the number of type parameters in the associated function of an impl and its trait differ, we now *always* point at the trait one, even if it comes from a foreign crate. When it is local, we point at the specific params, when it is foreign, we point at the whole associated item.
Fix #69944.
|
|
Mention `into_iter` on borrow errors suggestions when appropriate
If we encounter a borrow error on `vec![1, 2, 3].iter()`, suggest `into_iter`.
Fix #68445.
|
|
coverage: Fix inconsistent handling of function signature spans
While doing some more cleanup of `spans`, I noticed a strange inconsistency in how function signatures are handled. Normally the function signature span is treated as though it were executable as part of the start of the function, but in some cases the signature span disappears entirely from coverage, for no obvious reason.
This is caused by the fact that spans created by `CoverageSpan::for_fn_sig` don't add the span to their `merged_spans` field (unlike normal statement/terminator spans). In cases where the span-processing code looks at those merged spans, it thinks the signature span is no longer visible and deletes it.
Adding the signature span to `merged_spans` resolves the inconsistency.
(Prior to #116409 this wouldn't have been possible, because there was no case in the old `CoverageStatement` enum representing a signature. Now that `merged_spans` is just a list of spans, that's no longer an obstacle.)
|
|
Add stable Instance::body() and RustcInternal trait
The `Instance::body()` returns a monomorphized body.
For that, we had to implement visitor that monomorphize types and constants. We are also introducing the RustcInternal trait that will allow us to convert back from Stable to Internal.
Note that this trait is not yet visible for our users as it depends on Tables. We should probably add a new trait that can be exposed.
The tests here are very simple, and I'm planning on creating more exhaustive tests in the project-mir repo. But I was hoping to get some feedback here first.
r? ```@oli-obk```
|
|
Typo suggestion to change bindings with leading underscore
When encountering a binding that isn't found but has a typo suggestion for a binding with a leading underscore, suggest changing the binding definition instead of the use place.
Fix #60164.
|
|
coverage: Simplify the injection of coverage statements
This is a follow-up to #116046 that I left out of that PR because I didn't want to make it any larger.
After the various changes we've made to how coverage data is stored and transferred, the old code structure for injecting coverage statements into MIR is built around a lot of constraints that don't exist any more. We can simplify it by replacing it with a handful of loops over the BCB node/edge counters and the BCB spans.
---
`@rustbot` label +A-code-coverage
|
|
Suggest relaxing implicit `type Assoc: Sized;` bound
Fix #85378.
|
|
std: freebsd build update.
since freebsd 11 had been removed, minimum is now 12.
|
|
Miri subtree update
r? `@ghost`
|
|
|
|
Automatic Rustup
|
|
|
|
|
|
|
|
This query has a name that sounds general-purpose, but in fact it has
coverage-specific semantics, and (fortunately) is only used by coverage code.
Because it is only ever called once (from one designated CGU), it doesn't need
to be a query, and we can change it to a regular function instead.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When the number of type parameters in the associated function of an impl
and its trait differ, we now *always* point at the trait one, even if it
comes from a foreign crate. When it is local, we point at the specific
params, when it is foreign, we point at the whole associated item.
Fix #69944.
|
|
rename Generator to Coroutine
implements https://github.com/rust-lang/compiler-team/issues/682
While I did an automated replacement, I went through all changes manually to avoid renaming things like "id generators", "code generator", ...
I renamed files where that was necessary due to the contents referring to the crate name itself (mir opt, codegen or debuginfo tests), or required by tidy (feature gate docs)
* [x] rename various remaining abbreviated references to generators.
* [x] rename files
* [x] rename folders
* [x] add renamed feature: `generators`, ...
r? `@ghost`
|
|
|
|
|
