| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Make tidy check for lang gate tests
Add gate tests to the checks that tidy performs. Excerpt from the commit message of the main commit:
Require compile-fail tests for new lang features
Its non trivial to test lang feature gates, and people
forget to add such tests. So we extend the features lint
of the tidy tool to ensure that all new lang features
contain a new compile-fail test.
Of course, one could drop this requirement and just
grep all tests in run-pass for #![feature(abc)] and
then run this test again, removing the mention,
requiring that it fails.
But this only tests for the existence of a compilation
failure. Manual tests ensure that also the correct lines
spawn the error, and also test the actual error message.
For library features, it makes no sense to require such
a test, as here code is used that is generic for all
library features.
The tidy lint extension now checks the compile-fail test suite for occurences of "gate-test-X" where X is a feature. Alternatively, it also accepts file names with the form "feature-gate-X.rs". If a lang feature is found that has no such check, we emit a tidy error.
I've applied the markings to all tests I could find in the test suite. I left a small (20 elements) whitelist of features that right now have no gate test, or where I couldn't find one. Once this PR gets merged, I'd like to close issue #22820 and open a new one on suggestion of @nikomatsakis to track the removal of all elements from that whitelist (already have a draft). Writing such a small test can be a good opportunity for a first contribution, so I won't touch it (let others have the fun xD).
cc @brson , @pnkfelix (they both discussed about this in the issue linked above).
|
|
Provide the following output:
```
error[E0277]: the trait bound `Bar: Foo<usize>` is not satisfied
--> $DIR/issue-21659-show-relevant-trait-impls-2.rs:38:8
|
38 | f1.foo(1usize);
| ^^^ the trait `Foo<usize>` is not implemented for `Bar`
|
= help: the following implementations were found:
<Bar as Foo<i8>>
<Bar as Foo<i16>>
<Bar as Foo<i32>>
<Bar as Foo<u8>>
and 2 others
error: aborting due to previous error
```
instead of
```
error[E0277]: the trait bound `Bar: Foo<usize>` is not satisfied
--> $DIR/issue-21659-show-relevant-trait-impls-2.rs:38:8
|
38 | f1.foo(1usize);
| ^^^ the trait `Foo<usize>` is not implemented for `Bar`
|
= help: the following implementations were found:
= help: <Bar as Foo<i8>>
= help: <Bar as Foo<i16>>
= help: <Bar as Foo<i32>>
= help: <Bar as Foo<u8>>
= help: and 2 others
error: aborting due to previous error
```
|
|
resolve: Do not use "resolve"/"resolution" in error messages
Use less jargon-y wording instead.
`cannot find <struct> <S> in <this scope>` and `cannot find <struct> <S> in <module a::b>` are used for base messages (this also harmonizes nicely with "you can import it into scope" suggestions) and `not found in <this scope>` and `not found in <a::b>` are used for short labels in fall-back case.
I tweaked some other diagnostics to avoid using "resolve" (see, e.g., `librustc_resolve/macros.rs`), but haven't touched messages for imports.
Closes https://github.com/rust-lang/rust/issues/38750
r? @nrc
|
|
More jemalloc fixes
- Disable jemalloc on s390x as well (closes #38596)
- Disable jemalloc tests on platforms where it is disabled (closes #38612)
|
|
Rebase on top of PR 38814 made required this.
|
|
For a given file
```rust
trait A { fn foo(&self) {} }
trait B : A { fn foo(&self) {} }
fn bar<T: B>(a: &T) {
a.foo()
}
```
provide the following output
```
error[E0034]: multiple applicable items in scope
--> file.rs:6:5
|
6 | a.foo(1)
| ^^^ multiple `foo` found
|
note: candidate #1 is defined in the trait `A`
--> file.rs:2:11
|
2 | trait A { fn foo(&self, a: usize) {} }
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
help: to use it here write `A::foo(&a, 1)` instead
--> file.rs:6:5
|
6 | a.foo(1)
| ^^^
note: candidate #2 is defined in the trait `B`
--> file.rs:3:15
|
3 | trait B : A { fn foo(&self, a: usize) {} }
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
help: to use it here write `B::foo(&a, 1)` instead
--> file.rs:6:5
|
6 | a.foo(1)
| ^^^
```
|
|
Now, no feature outside of the whitelist is
without a test marked as its gate test.
|
|
|
|
|
|
syntax: enable attributes and cfg on struct fields
This enables conditional compilation of field initializers in a struct literal, simplifying construction of structs whose fields are themselves conditionally present. For example, the intializer for the constant in the following becomes legal, and has the intuitive effect:
```rust
struct Foo {
#[cfg(unix)]
bar: (),
}
const FOO: Foo = Foo {
#[cfg(unix)]
bar: (),
};
```
It's not clear to me whether this calls for the full RFC process, but the implementation was simple enough that I figured I'd begin the conversation with code.
|
|
See also #37392
|
|
|
|
|
|
resolve: clean up the semantics of `self` in an import list
Change `self` in an import list `use foo::bar::{self, ...};` to import `bar` only in the type namespace. Today, `bar` is imported in every namespace in which `foo::bar` is defined.
This is a [breaking-change], see https://github.com/rust-lang/rust/issues/38293#issue-194817974 for examples of code that would break.
Fixes #38293.
r? @nrc
|
|
Fix ICE when variant is used as a part of associated path
Fixes https://github.com/rust-lang/rust/issues/38862
r? @jseyfried
|
|
CC #34761
|
|
Fixes #38604
needs a crater run
|
|
This should be the last time I fix this function.
Fixes #38404.
|
|
|
|
module or enum `foo`.
|
|
Make members of {std,core}::{i128,u128} unstable
Fixes #38860
|
|
|
|
[11/n] Separate ty::Tables into one per each body.
_This is part of a series ([prev](https://github.com/rust-lang/rust/pull/38449) | [next]()) of patches designed to rework rustc into an out-of-order on-demand pipeline model for both better feature support (e.g. [MIR-based](https://github.com/solson/miri) early constant evaluation) and incremental execution of compiler passes (e.g. type-checking), with beneficial consequences to IDE support as well.
If any motivation is unclear, please ask for additional PR description clarifications or code comments._
<hr>
In order to track the results of type-checking and inference for incremental recompilation, they must be stored separately for each function or constant value, instead of lumped together.
These side-`Tables` also have to be tracked by various passes, as they visit through bodies (all of which have `Tables`, even if closures share the ones from their parent functions). This is usually done by switching a `tables` field in an override of `visit_nested_body` before recursing through `visit_body`, to the relevant one and then restoring it - however, in many cases the nesting is unnecessary and creating the visitor for each body in the crate and then visiting that body, would be a much cleaner solution.
To simplify handling of inlined HIR & its side-tables, their `NodeId` remapping and entries HIR map were fully stripped out, which means that `NodeId`s from inlined HIR must not be used where a local `NodeId` is expected. It might be possible to make the nodes (`Expr`, `Block`, `Pat`, etc.) that only show up within a `Body` have IDs that are scoped to that `Body`, which would also allow `Tables` to use `Vec`s.
That last part also fixes #38790 which was accidentally introduced in a previous refactor.
|
|
E0088/E0090 fix
This fixes an issue reported by @eddyb (https://github.com/rust-lang/rust/pull/36208#issuecomment-2707092230) where the check for "too few lifetime parameters" was removed in one of the error message PRs.
I also removed the span shrinking from E0088, as early bound lifetimes give you a confusing underline in some cases.
r=eddyb
|
|
|
|
|
|
Adding it in a stable form was an accident.
It thankfully only leaked to nightly.
Fixes #38860
|
|
Fix handling of empty types in patterns.
Fix for #12609.
|
|
|
|
|
|
r=nikomatsakis
Dont check stability for items that are not pub to universe.
Dont check stability for items that are not pub to universe.
In other words, skip it for private and even `pub(restricted)` items, because stability checks are only relevant to things visible in other crates.
Fix #38412.
|
|
r=petrochenkov
resolve: don't `unused_qualifications`-check global paths
We started `unused_qualifications`-checking global paths in #38014, causing #38682.
Fixes #38682.
r? @nrc
|
|
|
|
Fix associated types in copy implementations
Fixes an ICE and an error in checking copy implementations.
r? @nikomatsakis
|
|
Properly ban the negation of unsigned integers in type-checking.
Lint-time banning of unsigned negation appears to be vestigial from a time it was feature-gated.
But now it always errors and we do have the ability to deref the checking of e.g. `-0`, through the trait obligation fulfillment context, which will only succeed/error when the `0` gets inferred to a specific type.
The two removed tests are the main reason for finally cleaning this up, they need changing all the time when refactoring the HIR-based `rustc_const_eval` and/or `rustc_passes::consts`, as warnings pile up.
|
|
|
|
|
|
Span the affected fields instead of reporting the field/variant name.
|
|
|
|
drive-by: fix merge conflict; fix test expected error output post rebase.
|
|
```rust
let vr = v.iter().filter(|x| {
x % 2 == 0
});
```
will now yield the following compiler output:
```bash
ERROR binary operation `%` cannot be applied to type `&&_`
NOTE this is a reference of a reference to a type that `%` can be applied to,
you need to dereference this variable once for this operation to work
NOTE an implementation of `std::ops::Rem` might be missing for `&&_`
```
The first NOTE is new.
Bug #33877
|
|
|
|
|
|
|
|
|
|
|
|
Changes the non-exhaustive match error message to generate more general
witnesses.
|
|
|
|
|
|
|
