First, we keep a `CoerceMany` now to find the LUB of all the break
expressions. Second, this `CoerceMany` is actually an
`Option<CoerceMany>`, and we store `None` for loops where "break with an
expression" is disallowed. This avoids silly duplicate errors about a
type mismatch, since the loops pass already reports an error that the
break cannot have an expression. Finally, since we now detect an invalid
break target during HIR lowering, refactor `find_loop` to be infallible.
Adjust tests as needed:
- some spans from breaks are slightly different
- break up a single loop into multiple since `CoerceMany` silences
redundant and derived errors
- add a ui test that we only give on error for loop-break-value
Instead, wait until coercion time. This has some small effects on a few
tests (one less temporary, generally better errors when trying to call
methods or otherwise "force" the type).
`match { }` now (correctly?) indicates divergence, which results in more
unreachable warnings. We also avoid fallback to `!` if there is just one
arm (see new test: `match-unresolved-one-arm.rs`).
The new strategy is as follows. First, the `!` type is assigned
in two cases:
- a block with a diverging statement and no tail expression (e.g.,
`{return;}`);
- any expression with the type `!` is considered diverging.
Second, we track when we are in a diverging state, and we permit a value
of any type to be coerced **into** `!` if the expression that produced
it is diverging. This means that `fn foo() -> ! { panic!(); 22 }`
type-checks, even though the block has a type of `usize`.
Finally, coercions **from** the `!` type to any other are always
permitted.
Fixes#39808.
macros: improve `Span`'s expansion information
This PR improves `Span`'s expansion information. More specifically:
- It refactors AST node span construction to preserve expansion information.
- Today, we only use the underlying tokens' `BytePos`s, throwing away the `ExpnId`s.
- This improves the accuracy of AST nodes' expansion information, fixing #30506.
- It refactors `span.expn_id: ExpnId` to `span.ctxt: SyntaxContext` and removes `ExpnId`.
- This gives all tokens as much hygiene information as `Ident`s.
- This is groundwork for procedural macros 2.0 `TokenStream` API.
- This is also groundwork for declarative macros 2.0, which will need this hygiene information for some non-`Ident` tokens.
- It simplifies processing of spans' expansion information throughout the compiler.
- It fixes#40649.
- It fixes#39450 and fixes part of #23480.
r? @nrc
Clarify suggetion for field used as method
Instead of
```rust
error: no method named `src_addr` found for type `&wire::ipv4::Repr` in the current scope
--> src/wire/ipv4.rs:409:34
|
409 | packet.set_src_addr(self.src_addr());
| ^^^^^^^^
|
note: did you mean to write `self.src_addr`?
--> src/wire/ipv4.rs:409:34
|
409 | packet.set_src_addr(self.src_addr());
| ^^^^^^^^
```
present
```rust
error: no method named `src_addr` found for type `&wire::ipv4::Repr` in the current scope
--> src/wire/ipv4.rs:409:34
|
409 | packet.set_src_addr(self.src_addr());
| ^^^^^^^^ field, not a method
|
= help: did you mean to write `self.src_addr` instead of `self.src_addr(...)`?
```
Fix#38321.
borrowck: consolidate `mut` suggestions
This converts all of borrowck's `mut` suggestions to a new
`mc::ImmutabilityBlame` API instead of the current mix of various hacks.
Fixes#35937.
Fixes#40823.
Fixes#40859.
cc @estebank
r? @pnkfelix
store a copy of the Issue32230 info within TypeError
The data can't be looked up from the region variable directly, because
the region variable might have been destroyed at the end of a snapshot.
Fixes#40000.
Fixes#40743.
beta-nominating because regression.
r? @nikomatsakis
keep the AST node-id when lowering ExprKind::Range
When the Range expression is the root of a constant, its node-id is
used for the def-id of the body, so it has to be preserved in the AST ->
HIR lowering.
Fixes#40749.
r? @eddyb
beta-nominating because regression
This converts all of borrowck's `mut` suggestions to a new
`mc::ImmutabilityBlame` API instead of the current mix of various hacks.
Fixes#35937.
Fixes#40823.
Allow `use` macro imports to shadow global macros
Terminology:
- global scope: builtin macros, macros from the prelude, `#[macro_use]`, or `#![plugin(..)]`.
- legacy scope: crate-local `macro_rules!`.
- modern scope: `use` macro imports, `macro` (once implemented).
Today, the legacy scope can shadow the global scope (modulo RFC 1560 expanded shadowing restrictions). However, the modern scope cannot shadow or be shadowed by either the global or legacy scopes, leading to ambiguity errors.
This PR allows the modern scope to shadow the global scope (subject to some restrictions).
More specifically, a name in the global scope is as shadowable as a glob import in the module `self`. In other words, we imagine a special, implicit glob import in each module item:
```rust
mod foo {
#[lexical_only] // Not accessible via `foo::<name>`, like pre-RFC 1560 `use` imports.
#[shadowable_by_legacy_scope] // for back-compat
use <global_macros>::*;
}
```
r? @nrc
The data can't be looked up from the region variable directly, because
the region variable might have been destroyed at the end of a snapshot.
Fixes#40000.
Fixes#40743.
Instead of
```
error: no method named `src_addr` found for type `&wire::ipv4::Repr` in the current scope
--> src/wire/ipv4.rs:409:34
|
409 | packet.set_src_addr(self.src_addr());
| ^^^^^^^^
|
note: did you mean to write `self.src_addr`?
--> src/wire/ipv4.rs:409:34
|
409 | packet.set_src_addr(self.src_addr());
| ^^^^^^^^
```
present
```
error: no method named `src_addr` found for type `&wire::ipv4::Repr` in the current scope
--> src/wire/ipv4.rs:409:34
|
409 | packet.set_src_addr(self.src_addr());
| ^^^^^^^^ `src_addr` is a field, not a method
|
= help: did you mean to write `self.src_addr` instead of `self.src_addr(...)`?
```
Add warning for use of lifetime parameter with 'static bound
Previously a `'static` lifetime bound would result in an `undeclared lifetime` error when compiling, even though it could be considered valid.
However, it is unnecessary to use it as a lifetime bound so we present the user with a warning instead and suggest using the `'static` lifetime directly, in place of the lifetime parameter. We can change this to an error (or warning with lint) if that's decided to be more appropriate.
Example output:
```
warning: unnecessary lifetime parameter `'a`
--> ../static-lifetime-bound.rs:3:10
|
3 | fn f<'a: 'static>(val: &'a i32) {
| ^^^^^^^^^^^
|
= help: you can use the `'static` lifetime directly, in place `'a`
```
Fixes#40661
r? @jseyfried
Previously a `'static` lifetime bound would result in an `undeclared
lifetime` error when compiling, even though it could be considered
valid.
However, it is unnecessary to use it as a lifetime bound so we present
the user with a warning instead and suggest using the `'static` lifetime
directly, in place of the lifetime parameter.
Revert #39485, fixing type-inference regressions
This reverts PR #39485, which should fix the immediate regressions. Eventually I'd like to land https://github.com/rust-lang/rust/pull/40224 -- or some variant of it -- which revisits the question fo dead-code and inference.
r? @eddyb
cc @canndrew
When the Range expression is the root of a constant, its node-id is
used for the def-id of the body, so it has to be preserved in the AST ->
HIR lowering.
Fixes#40749.
Change object safety violation message
Hello!
This is my first pull request to rust so hopefully all goes well. This PR should fix issue #40670. I changed the error message in object_safety.rs and the corresponding compile-fail test in object-safety-supertrait-mentions-Self.rs.
Once the changes were made, I ran ```python x.py test src/tools/tidy``` and ```python x.py test```. Tidy passed and the compile-fail tests passed, however the test suite failed on the tcp tests as my machine has IPv6 disabled. I'm not sure what to do in this case besides letting travis run the suite against my changes. Please let me know if there's anything I can do to help further.
Thanks!
Mandeep
Add diagnostic for incorrect `pub (restriction)`
Given the following statement
```rust
pub (a) fn afn() {}
```
Provide the following diagnostic:
```rust
error: incorrect restriction in `pub`
--> file.rs:15:1
|
15 | pub (a) fn afn() {}
| ^^^
|
= help: some valid visibility restrictions are:
`pub(crate)`: visible only on the current crate
`pub(super)`: visible only in the current module's parent
`pub(in path::to::module)`: visible only on the specified path
help: to make this visible only to module `a`, add `in` before the path:
| pub (in a) fn afn() {}
```
Follow up to #40340, fix#40599, cc #32409.
Given the following statement
```rust
pub (a) fn afn() {}
```
Provide the following diagnostic:
```rust
error: incorrect restriction in `pub`
--> file.rs:15:1
|
15 | pub (a) fn afn() {}
| ^^^^^^^
|
= help: some valid visibility restrictions are:
`pub(crate)`: visible only on the current crate
`pub(super)`: visible only in the current module's parent
`pub(in path::to::module)`: visible only on the specified path
help: to make this visible only to module `a`, add `in` before the path:
| pub (in a) fn afn() {}
```
Remove cruft from old `pub(path)` syntax.
Introduce HirId, a replacement for ast::NodeId after lowering to HIR
This is the first step towards implementing #40303. This PR introduces the `HirId` type and generates a `HirId` for everything that would be assigned one (i.e. stuff in the HIR), but the HIR data types still use `NodeId` for now. Changing that is a big refactoring that I want to do in a separate PR.
A `HirId` uniquely identifies a node in the HIR of the current crate. It is composed of the `owner`, which is the `DefIndex` of the directly enclosing `hir::Item`, `hir::TraitItem`, or `hir::ImplItem` (i.e. the closest "item-like"), and the `local_id` which is unique within the given owner.
This PR is also running a number of consistency checks for the generated `HirId`s:
- Does `NodeId` in the HIR have a corresponding `HirId`?
- Is the `owner` part of each `HirId` consistent with its position in the HIR?
- Do the numerical values of the `local_id` part all lie within a dense range of integers?
cc @rust-lang/compiler
r? @eddyb or @nikomatsakis
Forbid conflicts between macros 1.0 exports and macros 2.0 exports
This PR forbids for conflicts between `#[macro_export]`/`#[macro_reexport]` macro exports and `pub use` macro exports. For example,
```rust
// crate A:
pub use macros::foo;
//^ This is allowed today, will be forbidden by this PR.
// crate B:
extern crate A; // This triggers a confusing error today.
use A::foo; // This could refer to refer to either macro export in crate A.
```
r? @nrc
HirId has a more stable representation than NodeId, meaning that
modifications to one item don't influence (part of) the IDs within
other items. The other part is a DefIndex for which there already
is a way of stable hashing and persistence.
This commit introduces the HirId type and generates a HirId for
every NodeId during HIR lowering, but the resulting values are
not yet used anywhere, except in consistency checks.
This reverts commit dc0bb3f283, reversing
changes made to e879aa43ef.
This is a temporary step intended to fix regressions. A more
comprehensive fix for type inference and dead-code is in the works.
Add feature gate for rvalue-static-promotion
Probably needs more tests (which ones?) and there may be other things that need to be done. Also not sure whether the version that introduces the flag is really `1.15.1`.
See https://github.com/rust-lang/rfcs/pull/1414.
Updates #38865.
