Rename _ to {integer} and {float} for unknown numeric types
This PR renames _ to {integer} or {float} for unknown numeric types, to help people parse error messages that have numeric types that haven't been nailed down.
Example:
```rust
fn main() {
let x: String = 4;
}
```
Before:
```
error[E0308]: mismatched types
--> quicktest.rs:2:21
|
2 | let x: String = 4;
| ^ expected struct `std::string::String`, found integral variable
|
= note: expected type `std::string::String`
= note: found type `_`
error: aborting due to previous error
```
after:
```
error[E0308]: mismatched types
--> quicktest.rs:2:21
|
2 | let x: String = 4;
| ^ expected struct `std::string::String`, found integral variable
|
= note: expected type `std::string::String`
= note: found type `{integer}`
error: aborting due to previous error
```
```
resolve: Exclude inaccessible names from single imports
If a single import resolves to an inaccessible name in some but not all namespaces, avoid importing the name in the inaccessible namespaces.
Currently, the inaccessible namespaces are imported but cause a privacy error when used.
r? @nrc
Centralize and clean type error reporting
Refactors the code that handles type errors to be cleaner and fixes various edge cases.
This made the already-bad "type mismatch resolving" error message somewhat uglier. I want to fix that in another commit before this PR is merged.
Fixes#31173
r? @jonathandturner, cc @nikomatsakis
Avoid reseting the thread local interner at the beginning of `phase_1_parse_input`
The thread local interner is used before `phase_1_parse_input` to create `InternedString`s, which currently wrap `Rc<String>`s. Once `InternedString` is refactored to be an interned string id (like `Name`), resetting will invalidate everything that was interned before `phase_1_parse_input`.
The resets were only useful for the `rusti` project, which can now use `driver::reset_thread_local_state`.
r? @nrc
The type equation in projection takes place under a binder and a snapshot, which
we can't easily take types out of. Instead, when encountering a projection error,
try to re-do the projection and find the type error then.
This fails to produce a sane type error when the failure was a "leak_check" failure.
I can't think of a sane way to show *these*, so I just left them use the old crappy
representation, and added a test to make sure we don't break them.
Refactor constant evaluation to use a single error reporting function
that reports a type-error-like message.
Also, unify all error codes with the "constant evaluation error" message
to just E0080, and similarly for a few other duplicate codes. The old
situation was a total mess, and now that we have *something* we can
further iterate on the UX.
Unfortunately, projection errors do not come with a nice set of
mismatched types. This is because the type equality check occurs
within a higher-ranked context. Therefore, only the type error
is reported. This is ugly but was always the situation.
I will introduce better errors for the lower-ranked case in
another commit.
Fixes the last known occurence of #31173
macros: fix bug in `stmt` matchers
Today, `stmt` matchers stop too early when parsing expression statements that begin with non-braced macro invocations. For example,
```rust
fn main() {
macro_rules! m { ($s:stmt;) => { $s } }
id!(vec![].push(0););
//^ Before this PR, the `stmt` matcher only consumes "vec![]", so this is an error.
//| After this PR, the `stmt` matcher consumes "vec![].push(0)", so this compiles.
}
```
This change is backwards compatible due to the follow set for `stmt`.
r? @eddyb
Do not resolve inherent static methods from other crates prematurely
Under some specific circumstances paths like `Type::method` can be resolved early in rustc_resolve instead of type checker. `Type` must be defined in another crate, it should be an enum or a trait object (i.e. a type that acts as a "module" in resolve), and `method` should be an inherent static method.
As a result, such paths don't go through `resolve_ufcs`, may be resolved incorrectly and break some invariants in type checker. This patch removes special treatment of such methods.
The removed code was introduced in 2bd46e767c to fix a problem that no longer exists.
r? @jseyfried
Fixed issue where importing a trait method directly and then calling the method causes a compiler panic
The code below triggers the panic, and is included in a new regression test.
```rust
trait Foo {
fn foo();
}
use Foo::foo;
fn main() {
foo();
}
```
The bug is caused by `librustc_resolve` allowing the illegal binding to be imported even after displaying the error message above.
The fix amounts to importing a dummy binding (`rustc::hir::def::Def::Err`) instead of the actual trait method.
If no NOTE assertions are present I believe they aren't asserted at all, and it
looks like the number of NOTEs differs on distcheck vs `make check`, so let's
just remove them all.
Closes#18154
This commit removed the restriction of only allowing one type per argument.
This is achieved by adding mappings between macro arguments and format
placeholders, then taking the mapping into consideration when emitting
the Arguments expression.
syntax_ext: format: fix implicit positional arguments
syntax_ext: format: don't panic if no args given for implicit positional args
Check the list lengths before use.
Fixes regression of `compile-fail/macro-backtrace-println.rs`.
syntax_ext: format: also map CountIsParam indices to expanded args
syntax_ext: format: fix ICE in case of malformed format args
Fix bugs in macro-expanded statement parsing
Fixes#34543.
This is a [breaking-change]. For example, the following would break:
```rust
macro_rules! m { () => {
println!("") println!("")
//^ Semicolons are now required on macro-expanded non-braced macro invocations
//| in statement positions.
let x = 0
//^ Semicolons are now required on macro-expanded `let` statements
//| that are followed by more statements, so this would break.
let y = 0 //< (this would still be allowed to reduce breakage in the wild)
}
fn main() { m!() }
```
r? @eddyb
Update definitions in def_map for associated types written in unqualified form (like `Self::Output`)
Cleanup finish_resolving_def_to_ty/resolve_ty_and_def_ufcs
Make VariantDef's available through constructor IDs
Correct inline assembly clobber formatting.
Fixes the formatting for inline assembly clobbers used in the book.
As this causes llvm to silently ignore the clobber an error is also
added to catch cases in which the wrong formatting was used.
Additionally a test case is added to confirm that this error works.
This fixes#34458
Note: this is only one out of a few possible ways to fix the issue
depending on how the asm! macro formatting is wanted.
Additionally, it'd be nicer to have some kind of test or feedback
from llvm if the clobber constraints are valid, but I do not know
enough about llvm to say if or how this is possible.
Revert "Revert "Remove the return_address intrinsic.""
This reverts commit f698cd3a36.
Made possible by the merge of servo/servo#11872, this closes#34227 for good.
Fixes the formatting for inline assembly clobbers used in the book.
As this causes llvm to silently ignore the clobber an error is also
added to catch cases in which the wrong formatting was used.
Additionally a test case is added to confirm that this error works.
Support `cfg_attr` on `path` attributes
Fixes#25544.
This is technically a [breaking-change]. For example, the following would break:
```rust
mod foo; // Suppose `foo.rs` existed in the appropriate location
```
std: Stabilize APIs for the 1.11.0 release
Although the set of APIs being stabilized this release is relatively small, the
trains keep going! Listed below are the APIs in the standard library which have
either transitioned from unstable to stable or those from unstable to
deprecated.
Stable
* `BTreeMap::{append, split_off}`
* `BTreeSet::{append, split_off}`
* `Cell::get_mut`
* `RefCell::get_mut`
* `BinaryHeap::append`
* `{f32, f64}::{to_degrees, to_radians}` - libcore stabilizations mirroring past
libstd stabilizations
* `Iterator::sum`
* `Iterator::product`
Deprecated
* `{f32, f64}::next_after`
* `{f32, f64}::integer_decode`
* `{f32, f64}::ldexp`
* `{f32, f64}::frexp`
* `num::One`
* `num::Zero`
Added APIs (all unstable)
* `iter::Sum`
* `iter::Product`
* `iter::Step` - a few methods were added to accomodate deprecation of One/Zero
Removed APIs
* `From<Range<T>> for RangeInclusive<T>` - everything about `RangeInclusive` is
unstable
Closes#27739Closes#27752Closes#32526Closes#33444Closes#34152
cc #34529 (new tracking issue)
Although the set of APIs being stabilized this release is relatively small, the
trains keep going! Listed below are the APIs in the standard library which have
either transitioned from unstable to stable or those from unstable to
deprecated.
Stable
* `BTreeMap::{append, split_off}`
* `BTreeSet::{append, split_off}`
* `Cell::get_mut`
* `RefCell::get_mut`
* `BinaryHeap::append`
* `{f32, f64}::{to_degrees, to_radians}` - libcore stabilizations mirroring past
libstd stabilizations
* `Iterator::sum`
* `Iterator::product`
Deprecated
* `{f32, f64}::next_after`
* `{f32, f64}::integer_decode`
* `{f32, f64}::ldexp`
* `{f32, f64}::frexp`
* `num::One`
* `num::Zero`
Added APIs (all unstable)
* `iter::Sum`
* `iter::Product`
* `iter::Step` - a few methods were added to accomodate deprecation of One/Zero
Removed APIs
* `From<Range<T>> for RangeInclusive<T>` - everything about `RangeInclusive` is
unstable
Closes#27739Closes#27752Closes#32526Closes#33444Closes#34152
cc #34529 (new tracking issue)
Revert "Remove the return_address intrinsic."
This reverts commit b30134dbc3.
Servo might want this merged if they don't merge servo/servo#11872 soon.
cc @pnkfelix @jdm
Disallow constants and statics from having unsized types.
This is a `[breaking-change]` which fixes#34390 by banning unsized `const` and `static`, e.g.:
```rust
const A: [i32] = *(&[0, 1, 2] as &[i32]);
static B: str = *"foo";
```
This was not intentionally allowed, and other than for `static` since some versions ago, it ICE'd.
If you've been taking advantage of this with `static`, you should be able to just use references instead.
