| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 5 pull requests
Successful merges:
- #78606 (Clarify handling of final line ending in str::lines())
- #78610 (Do not remove tokens before AST json serialization)
- #78620 (Trivial fixes to bitwise operator documentation)
- #78627 (Point out that total_cmp is no strict superset of partial comparison)
- #78637 (Add fetch_update methods to AtomicBool and AtomicPtr)
Failed merges:
r? `@ghost`
|
|
|
|
|
|
|
|
|
|
|
|
Do not remove tokens before AST json serialization
`TokenStripper` is error-prone and introduces one more use of `MutVisitor`.
It's much simpler to treat serialization as just one more place that wants lazy token stream to turn into a real token stream.
Also, no code is better than more code, in general.
r? @Aaron1011
(I also merged tests for `TokenStripper` ICEs into one.)
|
|
|
|
Implement rustc side of report-future-incompat
cc https://github.com/rust-lang/rust/issues/71249
This is an alternative to `@pnkfelix's` initial implementation in https://github.com/pnkfelix/rust/commits/prototype-rustc-side-of-report-future-incompat (mainly because I started working before seeing that branch :smile: ).
My approach outputs the entire original `Diagnostic`, in a way that is compatible with incremental compilation. This is not yet integrated with compiletest, but can be used manually by passing `-Z emit-future-incompat-report` to `rustc`.
Several changes are made to support this feature:
* The `librustc_session/lint` module is moved to a new crate `librustc_lint_defs` (name bikesheddable). This allows accessing lint definitions from `librustc_errors`.
* The `Lint` struct is extended with an `Option<FutureBreakage>`. When present, it indicates that we should display a lint in the future-compat report. `FutureBreakage` contains additional information that we may want to display in the report (currently, a `date` field indicating when the crate will stop compiling).
* A new variant `rustc_error::Level::Allow` is added. This is used when constructing a diagnostic for a future-breakage lint that is marked as allowed (via `#[allow]` or `--cap-lints`). This allows us to capture any future-breakage diagnostics in one place, while still discarding them before they are passed to the `Emitter`.
* `DiagnosticId::Lint` is extended with a `has_future_breakage` field, indicating whether or not the `Lint` has future breakage information (and should therefore show up in the report).
* `Session` is given access to the `LintStore` via a new `SessionLintStore` trait (since `librustc_session` cannot directly reference `LintStore` without a cyclic dependency). We use this to turn a string `DiagnosticId::Lint` back into a `Lint`, to retrieve the `FutureBreakage` data.
Currently, `FutureBreakage.date` is always set to `None`. However, this could potentially be interpreted by Cargo in the future.
I've enabled the future-breakage report for the `ARRAY_INTO_ITER` lint, which can be used to test out this PR. The intent is to use the field to allow Cargo to determine the date of future breakage (as described in [RFC 2834](https://github.com/rust-lang/rfcs/blob/master/text/2834-cargo-report-future-incompat.md)) without needing to parse the diagnostic itself.
cc `@pnkfelix`
|
|
Fix #78549
Before #78430, this worked because `specialize_constructor` didn't actually care too much which constructor was passed to it unless needed. That PR however handles `&str` as a special case, and I did not anticipate patterns for the `&str` type other than string literals.
I am not very confident there are not other similar oversights left, but hopefully only `&str` was different enough to break my assumptions.
Fixes https://github.com/rust-lang/rust/issues/78549
|
|
Suggest calling associated `fn` inside `trait`s
When calling a function that doesn't exist inside of a trait's
associated `fn`, and another associated `fn` in that trait has that
name, suggest calling it with the appropriate fully-qualified path.
Expand the label to be more descriptive.
Prompted by the following user experience:
https://users.rust-lang.org/t/cannot-find-function/50663
|
|
Before #78430, string literals worked because `specialize_constructor`
didn't actually care too much which constructor was passed to it unless
needed. Since then, string literals are special cased and a bit hacky. I
did not anticipate patterns for the `&str` type other than string
literals, hence this bug. This makes string literals less hacky.
|
|
|
|
The validator in visit_local asserts that local has a stroage when used,
but visit_local is never called so validation is ineffective.
Use super_statement and super_terminator to ensure that locals are visited.
|
|
Strip tokens from trait and impl items before printing AST JSON
Fixes #78510
|
|
Add regression test
This adds a regression test for #75777, effectively closing it since it is solved on nightly and beta.
Closes #75777
|
|
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #77334 (Reorder benches const variable)
- #77888 (Simplify a nested bool match)
- #77921 (f64: Refactor collapsible_if)
- #78523 (Revert invalid `fn` return type parsing change)
- #78524 (Avoid BorrowMutError with RUSTC_LOG=debug)
- #78545 (Make anonymous binders start at 0)
- #78554 (Improve wording of `core::ptr::drop_in_place` docs)
- #78556 (Link to pass docs from NRVO module docs)
Failed merges:
- #78424 (Fix some more clippy warnings)
r? `@ghost`
|
|
Make anonymous binders start at 0
A few changes to some test outputs, but these actually look *more* correct to me.
|
|
Avoid BorrowMutError with RUSTC_LOG=debug
```console
$ touch empty.rs
$ env RUSTC_LOG=debug rustc +stage1 --crate-type=lib empty.rs
```
Fails with a `BorrowMutError` because source map files are already
borrowed while `features_query` attempts to format a log message
containing a span.
Release the borrow before the query to avoid the issue.
|
|
Revert invalid `fn` return type parsing change
Revert one of the changes in #78379.
Fix #78507.
|
|
|
|
Always record reference to binding in match if guards
When encountering a binding from a `match` pattern in its `if` guard when computing a generator's interior types, we must always record the type of a reference to the binding because of how `if` guards are lowered to MIR. This was missed in #75213 because the binding in that test case was autorefed and we recorded that adjusted type anyway.
Fixes #78366
|
|
Handle type errors in closure/generator upvar_tys
Fixes #77993
|
|
|
|
Prefer new associated numeric consts in float error messages
Fix https://github.com/rust-lang/rust/issues/78382
|
|
Do not ICE on invalid input
Fix #78372.
|
|
Fixes #78510
|
|
|
|
Fix #78507.
|
|
Rollup of 11 pull requests
Successful merges:
- #77213 (rustdoc options to set default theme (and other settings))
- #78224 (min_const_generics: allow ty param in repeat expr)
- #78428 (MinConstGenerics UI test for invalid values for bool & char)
- #78460 (Adjust turbofish help message for const generics)
- #78470 (Clean up intra-doc links in `std::path`)
- #78475 (fix a comment in validity check)
- #78478 (Add const generics tests for supertraits + dyn traits.)
- #78487 (Fix typo "compiltest")
- #78491 (Inline NonZeroN::from(n))
- #78492 (Update books)
- #78494 (Fix typos)
Failed merges:
r? `@ghost`
|
|
Add const generics tests for supertraits + dyn traits.
Partially addresses #78433
|
|
Adjust turbofish help message for const generics
Types are no longer special. (This message arguably only makes sense with `min_const_generics` or more, but we'll be there soon.)
r? @lcnr
|
|
MinConstGenerics UI test for invalid values for bool & char
This adds a test for `feature(min_const_generics)` with some invalid values for bools and chars and ensures that they do not ICE and error with understandable messages.
r? @lcnr
|
|
min_const_generics: allow ty param in repeat expr
implements https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/repeat.20expressions
Even with `min_const_generics` active, now keeps resulting in future compat warnings instead of hard errors.
Const parameters, for example `[0; N + 1]`, still result in hard errors during resolve.
```rust
#![allow(dead_code)]
fn foo<T>() {
[0; std::mem::size_of::<*mut T>()];
}
struct Foo<T>(T);
impl<T> Foo<T> {
const ASSOC: usize = 4;
fn test() {
[0; Self::ASSOC];
}
}
```
r? @varkor cc @petrochenkov
|
|
Clarify main code paths in exhaustiveness checking
This PR massively clarifies the main code paths of exhaustiveness checking, by using the `Constructor` enum to a fuller extent. I've been itching to write it for more than a year, but the complexity of matching consts had prevented me. Behold a massive simplification :D.
This in particular removes a fair amount of duplication between various parts, localizes code into methods of relevant types when applicable, makes some implicit assumptions explicit, and overall improves legibility a lot (or so I hope). Additionally, after my changes undoing #76918 turned out to be a noticeable perf gain.
As usual I tried my best to make the commits self-contained and easy to follow. I've also tried to keep the code well-commented, but I tend to forget how complex this file is; I'm happy to clarify things as needed.
My measurements show good perf improvements on the two match-heavy benchmarks (-18.0% on `unicode_normalization-check`! :D); I'd like a perf run to check the overall impact.
r? `@varkor`
`@rustbot` modify labels: +A-exhaustiveness-checking
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 10 pull requests
Successful merges:
- #78152 (Separate unsized locals)
- #78297 (Suggest calling await on method call and field access)
- #78351 (Move "mutable thing in const" check from interning to validity)
- #78365 (check object safety of generic constants)
- #78379 (Tweak invalid `fn` header and body parsing)
- #78391 (Add const_fn in generics test)
- #78401 (resolve: private fields in tuple struct ctor diag)
- #78408 (Remove tokens from foreign items in `TokenStripper`)
- #78447 (Fix typo in comment)
- #78453 (Fix typo in comments)
Failed merges:
r? `@ghost`
|
|
Remove tokens from foreign items in `TokenStripper`
Fixes #78398
I forgot to handle this case in #77255
|
|
davidtwco:issue-75906-tuple-construct-private-field, r=estebank
resolve: private fields in tuple struct ctor diag
Fixes #75906.
This PR improves the diagnostic emitted when a tuple struct is being constructed which has private fields so that private fields are labelled and the message is improved.
r? @estebank
|
|
Add const_fn in generics test
Adds a test that constant functions in generic parameters work properly. I was surprised this works, but I also to turbofish the constant in main, otherwise it didn't infer properly:
```
let v: ConstU32<3> = ...
```
Did not work as I expected, which I can highlight in the test if that's the intended behaviour.
r? @lcnr
|
|
Tweak invalid `fn` header and body parsing
* Rely on regular "expected"/"found" parser error for `fn`, fix #77115
* Recover empty `fn` bodies when encountering `}`
* Recover trailing `>` in return types
* Recover from non-type in array type `[<BAD TOKEN>; LEN]`
|
|
check object safety of generic constants
As `Self` can only be effectively used in constants with `const_evaluatable_checked` this should not matter outside of it.
Implements the first item of #72219
> Object safety interactions with constants
r? @oli-obk for now cc @nikomatsakis
|
|
Move "mutable thing in const" check from interning to validity
This moves the check for mutable things (such as `UnsafeCell` or `&mut`) in a`const` from interning to validity. That means we can give more targeted error messages (pointing out *where* the problem lies), and we can simplify interning a bit.
Also fix the interning mode used for promoteds in statics.
r? @oli-obk
|
