Merge ObjectSum and PolyTraitRef in AST/HIR + some other refactoring
`ObjectSum` and `PolyTraitRef` are the same thing (list of bounds), they exist separately only due to parser quirks. The second commit merges them.
The first commit replaces `Path` with `Ty` in (not yet supported) equality predicates. They are parsed as types anyway and arbitrary types can always be disguised as paths using aliases, so this doesn't add any new functionality.
The third commit uses `Vec` instead of `P<[T]>` in AST. AST is not immutable like HIR and `Vec`s are more convenient for it, unnecessary conversions are also avoided.
The last commit renames `parse_ty_sum` (which is used for parsing types in general) into `parse_ty`, and renames `parse_ty` (which is used restricted contexts where `+` is not permitted due to operator priorities or other reasons) into `parse_ty_no_plus`.
This is the first part of https://github.com/rust-lang/rust/issues/39085#issuecomment-272743755 and https://github.com/rust-lang/rust/issues/39080 focused on data changes and mechanical renaming, I'll submit a PR with parser changes a bit later.
r? @eddyb
Fix lint attributes on non-item nodes.
Currently, late lint checking uses two HIR visitors: LateContext and
IdVisitor. IdVisitor only overrides visit_id, and for each node searches
for builtin lints previously added to the session; LateContext overrides
a number of methods, and runs late lints. When LateContext encounters an
item, it first has IdVisitor walk everything in it except nested items
(OnlyBodies), then recurses into it itself - i.e. there are two separate
walks.
Aside from apparently being unnecessary, this separation prevents lint
attributes (allow/deny/warn) on non-item HIR nodes from working
properly. Test case:
```rust
// generates warning without this change
fn main() { #[allow(unreachable_code)] loop { break; break; } }
```
LateContext contains logic to merge attributes seen into the current lint
settings while walking (with_lint_attrs), but IdVisitor does not. So
such attributes will affect late lints (because they are called from
LateContext), and if the node contains any items within it, they will
affect builtin lints within those items (because that IdVisitor is run
while LateContext is within the attributed node), but otherwise the
attributes will be ignored for builtin lints.
This change simply removes IdVisitor and moves its visit_id into
LateContext itself. Hopefully this doesn't break anything...
Also added walk calls to visit_lifetime and visit_lifetime_def
respectively, so visit_lifetime_def will recurse into the lifetime and
visit_lifetime will recurse into the name. In principle this could
confuse lint plugins. This is "necessary" because walk_lifetime calls
visit_id on the lifetime; of course, an alternative would be directly
calling visit_id (which would require manually iterating over the
lifetimes in visit_lifetime_def), but that seems less clean.
Use multiline Diagnostic for "relevant impl" list
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
```
Fix two const-eval issues related to i128 negation
First issue here was the fact that we’d only allow negating integers in i64 range in case the
integer was not infered yes. While this is not the direct cause of the issue, its still good to fix
it.
The real issue here is the code handling specifically the `min_value` literals. While I128_OVERFLOW
has the expected value (0x8000_..._0000), match using this value as a pattern is handled
incorrectly by the stage1 compiler (it seems to be handled correctly, by the stage2 compiler). So
what we do here is extract this pattern into an explicit `==` until the next snapshot.
Fixes#38987
trans: Treat generics like regular functions, not like #[inline] function, during CGU partitioning
This PR makes generics be treated just like regular functions during CGU partitioning:
+ the function instantiation is placed in a codegen unit based on the function's DefPath,
+ unless it is marked with `#[inline]` -- which causes a private copy of the function to be placed in every referencing codegen unit.
This has the following effects:
+ Multi codegen unit builds will become faster because code for generic functions is duplicated less.
+ Multi codegen unit builds might have lower runtime performance, since generics are not available for inlining automatically any more.
+ Single codegen unit builds are not affected one way or the other.
This partitioning scheme is particularly good for incremental compilation as it drastically reduces the number of false positives during codegen unit invalidation.
I'd love to have a benchmark suite for estimating the effect on runtime performance for changes like this one.
r? @nikomatsakis
cc @rust-lang/compiler
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
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.
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
First issue here was the fact that we’d only allow negating integers in i64 range in case the
integer was not infered yes. While this is not the direct cause of the issue, its still good to fix
it.
The real issue here is the code handling specifically the `min_value` literals. While I128_OVERFLOW
has the expected value (0x8000_..._0000), match using this value as a pattern is handled
incorrectly by the stage1 compiler (it seems to be handled correctly, by the stage2 compiler). So
what we do here is extract this pattern into an explicit `==` until the next snapshot.
Fixes#38987
fix function arguments in constant promotion
we can't create the target block until *after* we promote the arguments - otherwise the arguments will be promoted into the target block. oops.
Fixes#38985.
This is a regression introduced in the beta-nominated #38833, so beta-nominating this one too (sorry @brson).
r? @eddyb
we can't create the target block until *after* we promote the arguments
- otherwise the arguments will be promoted into the target block. oops.
Fixes#38985.
Teach diagnostics to correct margin of multiline messages
Make the suggestion list have a correct padding:
```
error[E0308]: mismatched types
--> file.rs:3:20
|
3 | let x: usize = "";
| ^^ expected usize, found reference
|
= note: expected type `usize`
= note: found type `&'static str`
= help: here are some functions which might fulfill your needs:
- .len()
- .foo()
- .bar()
```
Improved rustdoc rendering for unstable features
This replaces "unstable" with "this is an experimental API", and uses a `<details>` tag to expand to the reason.
The `<details>` tag renders as a regular div (with the details show) on browsers which don't support it, On browsers which do support it, it shows only the summary line with an expandy-arrow next to it, and on clicking it the details will turn up below it.
This is somewhat a strawman proposal. The main issue is that we need to improve our messaging around unstable APIs. Since they turn up in the docs, we should be clearer that they are experimental (and perhaps add something about nightly-only). I'm making this PR to kickstart discussion on this.
Example rendering: http://manishearth.github.io/rust-internals-docs/std/io/trait.Read.html#method.chars
<img width="375" alt="screen shot 2017-01-04 at 10 15 37 pm" src="https://cloud.githubusercontent.com/assets/1617736/21670712/5a96c7de-d2cb-11e6-86a6-87f70818d634.png">
expands to
<img width="799" alt="screen shot 2017-01-04 at 10 15 43 pm" src="https://cloud.githubusercontent.com/assets/1617736/21670714/5db88bb4-d2cb-11e6-8fcc-5cf11d198b75.png">
cc @steveklabnik @jdub
Remove destructor-related restrictions from unions
They don't have drop glue.
This doesn't fix the rvalue promotion issues when trying to do things like `static FOO: NoDrop<Bar> = NoDrop {inner: Bar}`. I'm not sure if we should fix that.
std: Add a nonblocking `Child::try_wait` method
This commit adds a new method to the `Child` type in the `std::process` module
called `try_wait`. This method is the same as `wait` except that it will not
block the calling thread and instead only attempt to collect the exit status. On
Unix this means that we call `waitpid` with the `WNOHANG` flag and on Windows it
just means that we pass a 0 timeout to `WaitForSingleObject`.
Currently it's possible to build this method out of tree, but it's unfortunately
tricky to do so. Specifically on Unix you essentially lose ownership of the pid
for the process once a call to `waitpid` has succeeded. Although `Child` tracks
this state internally to be resilient to multiple calls to `wait` or a `kill`
after a successful wait, if the child is waited on externally then the state
inside of `Child` is not updated. This means that external implementations of
this method must be extra careful to essentially not use a `Child`'s methods
after a call to `waitpid` has succeeded (even in a nonblocking fashion).
By adding this functionality to the standard library it should help canonicalize
these external implementations and ensure they can continue to robustly reuse
the `Child` type from the standard library without worrying about pid ownership.
