Update error format for E0062
Fixes#35217 as part of #35233
There seems to be an issue with the old format ignoring the labels which results in the incorrect line being rendered in the old format. I spoke with @jonathandturner about this and it seems to be a bug. Pertinent information [here](https://gist.github.com/trixnz/ad11e68687529e164427df8f8eb63116).
r? @jonathandturner
E0060 e0061 format update
This fixes#35215 and fixes#35216 as part of #35233
A separate issue will be opened to track the bonus portion of the tickets as @jaredwy will be handling that part.
?r @jonathandturner
Updated E0071 to new format.
Bonus: the span underlines only the name of the thing that's not a struct rather than the whole expression.
Part of #35233.
Fixes#35220.
r? @jonathandturner
Ignore deprecation for items deprecated by the same attribute
Whenever a node would be reported as deprecated:
- check if the parent item is also deprecated
- if it is and both were deprecated by the same attribute
- skip the deprecation warning
fixes#35128closes#16490
r? @eddyb
Properly enforce the "patterns aren't allowed in foreign functions" rule
Cases like `arg @ PATTERN` or `mut arg` were missing.
Apply the same rule to function pointer types.
Closes https://github.com/rust-lang/rust/issues/35203
[breaking-change], no breakage in sane code is expected though
r? @nikomatsakis
This is somewhat related to https://github.com/rust-lang/rfcs/pull/1685 (cc @matklad).
The goal is to eventually support full pattern syntax where it makes sense (function body may present) and to support *only* the following forms - `TYPE`, `ident: TYPE`, `_: TYPE` - where patterns don't make sense (function body doesn't present), i.e. in foreign functions and function pointer types.
Methods `Fn(Mut,Once)::call(mut,once)` are gated with two feature gates, remove one of them
Methods `Fn::call`, `FnMut::call_mut` and `FnOnce::call_once` are gated with usual library feature `fn_traits` and also hardcoded in the compiler and gated once more with feature `unboxed_closures`
This patch removes the `unboxed_closures`feature gate from these methods (`unboxed_closures` is still used for other things though), now they are gated only with `fn_traits`.
All unnecessary `#![feature(unboxed_closures)]`s are removed, many of them are old and were already unnecessary before the change this PR does.
typeck: use a TypeVisitor in ctp
Use a TypeVisitor in ctp instead of `ty::walk`
This fixes a few cases where a region could be projected out of a trait while not being constrained by the type parameters, violating rust-lang/rfcs#447 and breaking soundness. As such, this is a [breaking-change].
Fixes#35139
r? @eddyb
Avoid writing a temporary closure kind
We used to write a temporary closure kind into the inference table, but
this could lead to obligations being incorrectled resolved before
inference had completed. This result could then be cached, leading to
further trouble. This patch avoids writing any closure kind until the
computation is complete.
Fixes#34349.
r? @arielb1 -- what do you think?
diagnostically note source of overruling outer forbid
When we emit E0453 (lint level attribute overruled by outer `forbid`
lint level), it could be helpful to note where the `forbid` level was
set, for the convenience of users who, e.g., believe that the correct
fix is to weaken the `forbid` to `deny`.
Properly feature gate all unstable ABIs
Fixes https://github.com/rust-lang/rust/issues/34900
[breaking-change]
r? @pnkfelix
---
Function-visiting machinery for AST/HIR is surprisingly error-prone, it's *very* easy to miss some cases or visit something twice while writing a visitor. This is the true problem behind https://github.com/rust-lang/rust/issues/34900. I'll try to restructure these visitors a bit and send one more PR later.
When we emit E0453 (lint level attribute overruled by outer `forbid`
lint level), it could be helpful to note where the `forbid` level was
set, for the convenience of users who, e.g., believe that the correct
fix is to weaken the `forbid` to `deny`.
syntax_ext: format: fix ICE with bad named arguments
Fixes#35082 by guarding against a new case of malformed invocation not previously covered.
r? @alexcrichton
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
We used to write a temporary closure kind into the inference table, but
this could lead to obligations being incorrectled resolved before
inference had completed. This result could then be cached, leading to
further trouble. This patch avoids writing any closure kind until the
computation is complete.
Fixes#34349.
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.
Make the metadata lock more robust
Fixes#33778 and friends.
I also needed to add a metadata encoding version to rlibs, as they did not have it before. To keep it backwards-compatible, I added 4 zeroes to the start of the metadata, which are treated as an empty length field by older rustcs.
r? @alexcrichton
Revert "skip double negation in const eval"
This reverts commit 735c018974.
fixes#34395
The original commit was based on a mis-understanding of the overflowing literal lint.
This needs to be ported to beta.
r? @eddyb
Forbid type parameters and global paths in macro invocations
Fixes#28558.
This is a [breaking-change]. For example, the following would break:
```rust
macro_rules! m { () => { () } }
fn main() {
m::<T>!(); // Type parameters are no longer allowed in macro invocations
::m!(); // Global paths are no longer allowed in macro invocations
}
```
Any breakage can be fixed by removing the type parameters or the leading `::` (respectively).
r? @eddyb
Batch up libsyntax breaking changes
Batch of the following syntax-[breaking-change] changes:
- #34213: Add a variant `Macro` to `TraitItemKind`
- #34368: Merge the variant `QPath` of `PatKind` into the variant `PatKind::Path`
- #34385: Move `syntax::ast::TokenTree` into a new module `syntax::tokenstream`
- #33943:
- Remove the type parameter from `visit::Visitor`
- Remove `attr::WithAttrs` -- use `attr::HasAttrs` instead.
- Change `fold_tt`/`fold_tts` to take token trees by value and avoid wrapping token trees in `Rc`.
- Remove the field `ctxt` of `ast::Mac_`
- Remove inherent method `attrs()` of types -- use the method `attrs` of `HasAttrs` instead.
- #34316:
- Remove `ast::Decl`/`ast::DeclKind` and add variants `Local` and `Item` to `StmtKind`.
- Move the node id for statements from the `StmtKind` variants to a field of `Stmt` (making `Stmt` a struct instead of an alias for `Spanned<StmtKind>`)
- Rename `ast::ExprKind::Again` to `Continue`.
- #34339: Generalize and abstract `ThinAttributes` to `ThinVec<Attribute>`
- Use `.into()` in convert between `Vec<Attribute>` and `ThinVec<Attribute>`
- Use autoderef instead of `.as_attr_slice()`
- #34436: Remove the optional expression from `ast::Block` and instead use a `StmtKind::Expr` at the end of the statement list.
- #34403: Move errors into a separate crate (unlikely to cause breakage)
Remove the return_address intrinsic.
This intrinsic to get the return pointer was introduced in #16248 / #16081 by @pcwalton for Servo.
However, as explained in #34227, it's impossible to ensure it's used correctly, and it broke with `-Zorbit`.
Servo's usage is being replaced in servo/servo#11872, and I expect nobody else to have abused it.
But I've also started a crater run, just in case this is a `[breaking-change]` for anyone else.
To allow these braced macro invocation, this PR removes the optional expression from `ast::Block` and instead uses a `StmtKind::Expr` at the end of the statement list.
Currently, braced macro invocations in blocks can expand into statements (and items) except when they are last in a block, in which case they can only expand into expressions.
For example,
```rust
macro_rules! make_stmt {
() => { let x = 0; }
}
fn f() {
make_stmt! {} //< This is OK...
let x = 0; //< ... unless this line is commented out.
}
```
Fixes#34418.
This PR refactors the 'errors' part of libsyntax into its own crate (librustc_errors). This is the first part of a few refactorings to simplify error reporting and potentially support more output formats (like a standardized JSON output and possibly an --explain mode that can work with the user's code), though this PR stands on its own and doesn't assume further changes.
As part of separating out the errors crate, I have also refactored the code position portion of codemap into its own crate (libsyntax_pos). While it's helpful to have the common code positions in a separate crate for the new errors crate, this may also enable further simplifications in the future.
Revert a change in the scope of macros imported from crates to fix a regression
Fixes#34212.
The regression was caused by #34032, which changed the scope of macros imported from extern crates to match the scope of macros imported from modules.
r? @nrc
Support nested `cfg_attr` attributes
Support arbitrarily deeply nested `cfg_attr` attributes (e.g. `#[cfg_attr(foo, cfg_attr(bar, baz))]`).
This makes configuration idempotent.
Currently, the nighties do not support any `cfg_attr` nesting. Stable and beta support just one level of `cfg_attr` nesting (expect for attributes on macro-expanded nodes, where no nesting is supported).
This is a [breaking-change]. For example, the following would break:
```rust
macro_rules! m { () => {
#[cfg_attr(all(), cfg_attr(all(), cfg(foo)))]
fn f() {}
} }
m!();
fn main() { f() } //~ ERROR unresolved name `f`
```
r? @nrc
Show types of all args when missing args
When there're missing arguments in a function call, present a list of
all the expected types:
```rust
fn main() {
t("");
}
fn t(a: &str, x: String) {}
```
```bash
% rustc file.rs
file.rs:3:5: 2:8 error: this function takes 2 parameters but 0
parameters were supplied [E0061]
file.rs:3 t();
^~~
file.rs:3:5: 2:8 help: run `rustc --explain E0061` to see a detailed explanation
file.rs:3:5: 2:8 note: the following parameter types were expected: &str, std::string::String
error: aborting due to previous error
```
Fixes#33649
When there're missing arguments in a function call, present a list of
all the expected types:
```rust
fn main() {
t("");
}
fn t(a: &str, x: String) {}
```
```bash
% rustc file.rs
file.rs:3:5: 2:8 error: this function takes 2 parameters but 0
parameters were supplied [E0061]
file.rs:3 t();
^~~
file.rs:3:5: 2:8 help: run `rustc --explain E0061` to see a detailed explanation
file.rs:3:5: 2:8 note: the following parameter types were expected: &str, std::string::String
error: aborting due to previous error
```
Fixes#33649
derive Hash (and not Copy) for ranges
Fixes#34170.
Also, `RangeInclusive` was `Copy` by mistake -- fix that, which is a [breaking-change] to that unstable type.
Visit statement and expression attributes in the AST visitor
Currently, these attributes are not visited, so they are not gated feature checked in the post expansion visitor. This only affects crates using `#![feature(stmt_expr_attributes)]`.
r? @nrc
Fix issue #34101
Fix issue #34101: do not track subcontent of type with dtor nor gather flags for untracked content.
(Includes a regression test, which needed to go into `compile-fail/`
due to weaknesses when combining `#[deny(warnings)]` with
`tcx.sess.span_warn(..)`)
The root of the problem is that a string literal pattern is essentially of
the form `&LITERAL`, in a single block, while match checking wants to
split that.
To fix that, I added a type field to the patterns in match checking,
which allows us to distinguish between a full and split pattern.
That file is ugly and needs to be cleaned. However, `trans::_match` calls
it, so I think we should delay the cleanup until we kill that.
Fixes#30240
Remove the old FOLLOW checking (aka `check_matcher_old`).
It was supposed to be removed at the next release cycle but is still in the tree since like 6 months.
Potential breaking change, since some cases (such as #25658) will change from a warning to an error. But the warning stating that it will be a hard error in the next release has been there for 6 months now.
I think it's safe to break this code. ^_^
(Includes a regression test, which needed to go into `compile-fail/`
due to weaknesses when combining `#[deny(warnings)]` with
`tcx.sess.span_warn(..)`)
(updated with review feedback from arielb1.)
rustc: add ReErased to be used by trait selection, MIR and trans.
`ReErased` replaces `ReStatic` (i.e. `'static`) for erasing regions.
Using a distinct lifetime helps prevent accidental mix-ups between the two.
It also allows cleaner type printing (see test changes), including in symbol names:
```rust
str..pattern..CharSearcher$LT$$u27$static$GT$::drop.30560::h840c2f2afc03bbea // before
str..pattern..CharSearcher::drop.30561::h6bd31d2af614377a // after
```
Not that we should be producing symbols this way, but it's still better.
Fix a regression in the configuration folder
This fixes#34028, a regression caused by #33706 in which unconfigured impl items generated by a macro in an impl item position are not removed.
r? @nrc
Projection cache and better warnings for #32330
This PR does three things:
- it lays the groundwork for the more precise subtyping rules discussed in #32330, but does not enable them;
- it issues warnings when the result of a leak-check or subtyping check relies on a late-bound region which will late become early-bound when #32330 is fixed;
- it introduces a cache for projection in the inference context.
I'm not 100% happy with the approach taken by the cache here, but it seems like a step in the right direction. It results in big wins on some test cases, but not as big as previous versions -- I think because it is caching the `Vec<Obligation>` (whereas before I just returned the normalized type with an empty vector). However, that change was needed to fix an ICE in @alexcrichton's future-rs module (I haven't fully tracked the cause of that ICE yet). Also, because trans/the collector use a fresh inference context for every call to `fulfill_obligation`, they don't profit nearly as much from this cache as they ought to.
Still, here are the results from the future-rs `retry.rs`:
```
06:26 <nmatsakis> time: 6.246; rss: 44MB item-bodies checking
06:26 <nmatsakis> time: 54.783; rss: 63MB translation item collection
06:26 <nmatsakis> time: 140.086; rss: 86MB translation
06:26 <nmatsakis> time: 0.361; rss: 46MB item-bodies checking
06:26 <nmatsakis> time: 5.299; rss: 63MB translation item collection
06:26 <nmatsakis> time: 12.140; rss: 86MB translation
```
~~Another example is the example from #31849. For that, I get 34s to run item-bodies without any cache. The version of the cache included here takes 2s to run item-bodies type-checking. An alternative version which doesn't track nested obligations takes 0.2s, but that version ICEs on @alexcrichton's future-rs (and may well be incorrect, I've not fully convinced myself of that). So, a definite win, but I think there's definitely room for further progress.~~
Pushed a modified version which improves performance of the case from #31849:
```
lunch-box. time rustc --stage0 ~/tmp/issue-31849.rs -Z no-trans
real 0m33.539s
user 0m32.932s
sys 0m0.570s
lunch-box. time rustc --stage2 ~/tmp/issue-31849.rs -Z no-trans
real 0m0.195s
user 0m0.154s
sys 0m0.042s
```
Some sort of cache is also needed for unblocking further work on lazy normalization, since that will lean even more heavily on the cache, and will also require cycle detection.
r? @arielb1
Add AST validation pass and move some checks to it
The purpose of this pass is to catch constructions that fit into AST data structures, but not permitted by the language. As an example, `impl`s don't have visibilities, but for convenience and uniformity with other items they are represented with a structure `Item` which has `Visibility` field.
This pass is intended to run after expansion of macros and syntax extensions (and before lowering to HIR), so it can catch erroneous constructions that were generated by them. This pass allows to remove ad hoc semantic checks from the parser, which can be overruled by syntax extensions and occasionally macros.
The checks can be put here if they are simple, local, don't require results of any complex analysis like name resolution or type checking and maybe don't logically fall into other passes. I expect most of errors generated by this pass to be non-fatal and allowing the compilation to proceed.
I intend to move some more checks to this pass later and maybe extend it with new checks, like, for example, identifier validity. Given that syntax extensions are going to be stabilized in the measurable future, it's important that they would not be able to subvert usual language rules.
In this patch I've added two new checks - a check for labels named `'static` and a check for lifetimes and labels named `'_`. The first one gives a hard error, the second one - a future compatibility warning.
Fixes https://github.com/rust-lang/rust/issues/33059 ([breaking-change])
cc https://github.com/rust-lang/rfcs/pull/1177
r? @nrc
stable features lint warning mentions version stabilized
To accomplish this, we alter the checks in `rustc::middle::stability` to
use the `StabilityLevel` defined in `syntax::attr` (which includes the
version in which the feature was stabilized) rather than the local
`StabilityLevel` in the same module, and make the
`declared_stable_lang_features` field of
`syntax::feature_gate::Features` hold a Vec of feature-name, span
tuples (in analogy to the `declared_lib_features` field) rather than
just spans.
Fixes#33394.
r? @brson (tagging Brian because he [wrote](https://github.com/rust-lang/rust/pull/21958) the lint)
Reject a LHS formed of a single sequence TT during `macro_rules!` checking.
This was already rejected during expansion. Encountering malformed LHS or RHS during expansion is now considered a bug.
Follow up to #33689.
r? @pnkfelix
Note: this can break code that defines such macros but does not use them.
When we do a "HR subtype" check, we replace all late-bound regions (LBR)
in the subtype with fresh variables, and skolemize the late-bound
regions in the supertype. If those skolemized regions from the supertype
wind up being super-regions (directly or indirectly) of either
- another skolemized region; or,
- some region that pre-exists the HR subtype check
- e.g., a region variable that is not one of those created
to represent bound regions in the subtype
then the subtype check fails.
What will change when we fix#32330 is that some of the LBR in the
subtype may become early-bound. In that case, they would no longer be in
the "permitted set" of variables that can be related to a skolemized
type.
So the foundation for this warning is to collect variables that we found
to be related to a skolemized type. For each of them, we have a
`BoundRegion` which carries a `Issue32330` flag. We check whether any of
those flags indicate that this variable was created from a lifetime
that will change from late- to early-bound. If so, we issue a warning
indicating that the results of compilation may change.
This is imperfect, since there are other kinds of code that will not
compile once #32330 is fixed. However, it fixes the errors observed in
practice on crater runs.
Currently, we consider region subtyping a failure
if a skolemized lifetime is relatable to any
other lifetime in any way at all. But a more precise
formulation is to say that a skolemized lifetime:
- must not have any *incoming* edges in the region graph
- only has *outgoing* edges to nodes that are `'static`
To enforce the latter requirement, we add edges from `'static -> 'x` for
each lifetime '`x' reachable from a skolemized region.
We now have to add a new `pop_skolemized` routine to do cleanup.
Whereas before if there were *any* edges relating to a skolemized
region, we would return `Err` and hence rollback the transaction, we now
tolerate some edges and return `Ok`. Therefore, the `pop_skolemized`
routine runs and cleans up those edges.
To accomplish this, we alter the checks in `rustc::middle::stability` to
use the `StabilityLevel` defined in `syntax::attr` (which includes the
version in which the feature was stabilized) rather than the local
`StabilityLevel` in the same module, and make the
`declared_stable_lang_features` field of
`syntax::feature_gate::Features` hold a Vec of feature-name, span
tuples (in analogy to the `declared_lib_features` field) rather than
just spans.
This is in the matter of issue #33394.
refactor autoderef to avoid prematurely registering obligations
Refactor `FnCtxt::autoderef` to use an external iterator and to not
register any obligation from the main autoderef loop, but rather to
register them after (and if) the loop successfully completes.
Fixes#24819Fixes#25801Fixes#27631Fixes#31258Fixes#31964Fixes#32320Fixes#33515Fixes#33755
r? @eddyb
Increase spacing in error format for readability.
Two small tweaks that seem to help readability quite a bit:
* Add spacing header<->snippet, but use the |> on the side for visual consistency
* Fix#33819
* Fix#33763
* Move format-sensitive test (issue-26480 in cfail) to ui test
r? @nikomatsakis
Perform `cfg` attribute processing during macro expansion and fix bugs
This PR refactors `cfg` attribute processing and fixes bugs. More specifically:
- It merges gated feature checking for stmt/expr attributes, `cfg_attr` processing, and `cfg` processing into a single fold.
- This allows feature gated `cfg` variables to be used in `cfg_attr` on unconfigured items. All other feature gated attributes can already be used on unconfigured items.
- It performs `cfg` attribute processing during macro expansion instead of after expansion so that macro-expanded items are configured the same as ordinary items. In particular, to match their non-expanded counterparts,
- macro-expanded unconfigured macro invocations are no longer expanded,
- macro-expanded unconfigured macro definitions are no longer usable, and
- feature gated `cfg` variables on macro-expanded macro definitions/invocations are now errors.
This is a [breaking-change]. For example, the following would break:
```rust
macro_rules! m {
() => {
#[cfg(attr)]
macro_rules! foo { () => {} }
foo!(); // This will be an error
macro_rules! bar { () => { fn f() {} } }
#[cfg(attr)] bar!(); // This will no longer be expanded ...
fn g() { f(); } // ... so that `f` will be unresolved.
#[cfg(target_thread_local)] // This will be a gated feature error
macro_rules! baz { () => {} }
}
}
m!();
```
r? @nrc
Fix `asm-misplaced-option` on ARM/AArch64
This fixesrust-lang/rust#33737. Of course, since we don't run `make check` for ARM cross builds, you probably won't notice it.
Fixes to mir dataflow
Fixes to mir dataflow
This collects a bunch of changes to `rustc_borrowck::borrowck::dataflow` (which others have pointed out should probably migrate to some crate that isn't tied to the borrow-checker -- but I have not attempted that here, especially since there are competing approaches to dataflow that we should also evaluate).
These changes:
1. Provide a family of related analyses: MovingOutStatements (which is what the old AST-based dataflo computed), as well as MaybeInitialized, MaybeUninitalized, and DefinitelyInitialized.
* (The last two are actually inverses of each other; we should pick one and drop the other.)
2. Fix bugs in the pre-existing analysis implementation, which was untested and thus some obvious bugs went unnoticed, which brings us to the third point:
3. Add a unit test infrastructure for the MIR dataflow analysis.
* The tests work by adding a new intrinsic that is able to query the analysis state for a particular expression (technically, a particular L-value).
* See the examples in compile-fail/mir-dataflow/inits-1.rs and compile-fail/mir-dataflow/uninits-1.rs
* These tests are only checking the results for MaybeInitialized, MaybeUninitalized, and DefinitelyInitialized; I am not sure if it will be feasible to generalize this testing strategy to the MovingOutStatements dataflow operator.
Make sure that macros that didn't pass LHS checking are not expanded.
This avoid duplicate errors for things like invalid fragment specifiers, or
parsing errors for ambiguous macros.
Save metadata even with -Z no-trans (e.g. for multi-crate cargo check).
Removes the item symbol map in metadata, as we can now generate them in a deterministic manner.
The `-Z no-trans` change lets the LLVM passes and linking run, but with just metadata and no code.
It fails while trying to link a binary because there's no `main` function, which is correct but not good UX.
There's also no way to easily throw away all of the artifacts to rebuild with actual code generation.
We might want `cargo check` to do that using cargo-internal information and then it would just work.
cc @alexcrichton @nikomatsakis @Aatch @michaelwoerister
Refactor `FnCtxt::autoderef` to use an external iterator and to not
register any obligation from the main autoderef loop, but rather to
register them after (and if) the loop successfully completes.
Fixes#24819Fixes#25801Fixes#27631Fixes#31258Fixes#31964Fixes#32320Fixes#33515Fixes#33755
Allow `concat_idents!` in type positions as well as in expression positions
This allows the `concat_idents!` macro in type positions as well as in expression positions.
r? @nrc
rustc: Add a new crate type, cdylib
This commit is an implementation of [RFC 1510] which adds a new crate type,
`cdylib`, to the compiler. This new crate type differs from the existing `dylib`
crate type in a few key ways:
* No metadata is present in the final artifact
* Symbol visibility rules are the same as executables, that is only reachable
`extern` functions are visible symbols
* LTO is allowed
* All libraries are always linked statically
This commit is relatively simple by just plubming the compiler with another
crate type which takes different branches here and there. The only major change
is an implementation of the `Linker::export_symbols` function on Unix which now
actually does something. This helps restrict the public symbols from a cdylib on
Unix.
With this PR a "hello world" `cdylib` is 7.2K while the same `dylib` is 2.4MB,
which is some nice size savings!
[RFC 1510]: https://github.com/rust-lang/rfcs/pull/1510Closes#33132
This commit is an implementation of [RFC 1510] which adds a new crate type,
`cdylib`, to the compiler. This new crate type differs from the existing `dylib`
crate type in a few key ways:
* No metadata is present in the final artifact
* Symbol visibility rules are the same as executables, that is only reachable
`extern` functions are visible symbols
* LTO is allowed
* All libraries are always linked statically
This commit is relatively simple by just plubming the compiler with another
crate type which takes different branches here and there. The only major change
is an implementation of the `Linker::export_symbols` function on Unix which now
actually does something. This helps restrict the public symbols from a cdylib on
Unix.
With this PR a "hello world" `cdylib` is 7.2K while the same `dylib` is 2.4MB,
which is some nice size savings!
[RFC 1510]: https://github.com/rust-lang/rfcs/pull/1510Closes#33132
Only print parameters with elided lifetimes in elision error messages.
When displaying the function parameters for a lifetime elision error message,
this changes it to first filter out the parameters that don't have elided
lifetimes.
Fixes#30255.
Add regression tests for error message when using enum variant as a type
I'm guessing these were actually fixed with PR #27085.
Closes#21225Closes#19197
Fix for old school error issues, improvements to new school
This PR:
* Fixes some old school error issues, specifically #33559, #33543, #33366
* Improves wording borrowck errors with match patterns
* De-emphasize multi-line spans, so we don't color the single source character when we're trying to say "span starts here"
* Rollup of #33392 (which should help fix#33390)
r? @nikomatsakis
When displaying the function parameters for a lifetime elision error message,
this changes it to first filter out the parameters that don't have elided
lifetimes.
Fixes#30255.
Warnings for issue #32330
This is an extension of the previous PR that issues warnings in more situations than before. It does not handle *all* cases of #32330 but I believe it issues warnings for all cases I've seen in practice.
Before merging I'd like to address:
- open a good issue explaining the problem and how to fix it (I have a [draft writeup][])
- work on the error message, which I think is not as clear as it could/should be (suggestions welcome)
r? @aturon
[draft writeup]: https://gist.github.com/nikomatsakis/631ec8b4af9a18b5d062d9d9b7d3d967
Replace the obligation forest with a graph
In the presence of caching, arbitrary nodes in the obligation forest can be merged, which makes it a general graph. Handle it as such, using cycle-detection algorithms in the processing.
I should do performance measurements sometime.
This was pretty much written as a proof-of-concept. Please help me write this in a less-ugly way. I should also add comments explaining what is going on.
r? @nikomatsakis
Remove ExplicitSelf from HIR
`self` argument is already kept in the argument list and can be retrieved from there if necessary, so there's no need for the duplication.
The same changes can be applied to AST, I'll make them in the next breaking batch.
The first commit also improves parsing of method declarations and fixes https://github.com/rust-lang/rust/issues/33413.
r? @eddyb
Batch of improvements to errors for new error format
This is a batch of improvements to existing errors to help get the most out of the new error format.
* Added labels to primary spans (^^^) for a set of errors that didn't currently have them
* Highlight the source blue under the secondary notes for better readability
* Move some of the "Note:" into secondary spans+labels
* Fix span_label to take &mut instead, which makes it work the same as other methods in that set
typeck: if a private field exists, also check for a public method
For example, `Vec::len` is both a field and a method, and usually encountering `vec.len` just means that the parens were forgotten.
Fixes: #26472
NOTE: I added the parameter `allow_private` to `method::exists` since I don't want to suggest inaccessible methods. For the second case, where only the method exists, I think it would make sense to set it to `false` as well, but I wanted to preserve compatibility for this case.
const_fn: Check the terminating expression of a block for blocks in a const initializer
In a const or static initializer, the `CheckBlock` check ensures that blocks in the initializer expression are only in tail positions or in items. In this case, it didn't check the terminating expression of a block, which resulted in an ICE later in the compiler pipeline if the trailing expression was itself a block. This change fixes the ICE and ensures that the proper error is emitted. This fixes the ICE in #32829 .
Add rustc_on_unimplemented for Index implementation on slice
Reopening of #31071.
It also extends the possibility of `#[rustc_on_unimplemented]` by providing a small type filter in order to find the ones which corresponds the most.
r? @pnkfelix
fix DFS for region error reporting
This was causing terrible error reports, because the algorithm was incorrectly identifying the constraints.
r? @eddyb
borrowck: do not suggest to change "&mut self" to "&mut mut self"
Matching the snippet string might not be the cleanest, but matching
the AST node instead seems to end in a lot of nested `if let`s, so I
don't know what's better.
Of course it's entirely possible that there is another API altogether
that I just don't know of?
Fixes#31424.
resolve: do not modify span of non-importable name
This span modification is probably leftover from a time when import spans were assigned differently.
With this change, error spans for the following are properly reported:
```
use abc::one_el;
use abc::{a, bbb, cccccc};
use a_very_long_name::{el, el2};
```
before (spans only):
```
x.rs:3 use abc::one_el;
^~~
x.rs:4 use abc::{a, bbb, cccccc};
^~~
x.rs:4 use abc::{a, bbb, cccccc};
^~~
x.rs:4 use abc::{a, bbb, cccccc};
^~~
(internal compiler error: unprintable span)
(internal compiler error: unprintable span)
```
after:
```
x.rs:3 use abc::one_el;
^~~~~~~~~~~
x.rs:4 use abc::{a, bbb, cccccc};
^
x.rs:4 use abc::{a, bbb, cccccc};
^~~
x.rs:4 use abc::{a, bbb, cccccc};
^~~~~~
x.rs:5 use a_very_long_name::{el, el2};
^~
x.rs:5 use a_very_long_name::{el, el2};
^~~
```
Fixes: #33464
This span modification is probably leftover from a time when
import spans were assigned differently.
With this change, error spans for the following are properly reported:
```
use abc::one_el;
use abc::{a, bbb, cccccc};
use a_very_long_name::{el, el2};
```
before (spans only):
```
x.rs:3 use abc::one_el;
^~~
x.rs:4 use abc::{a, bbb, cccccc};
^~~
x.rs:4 use abc::{a, bbb, cccccc};
^~~
x.rs:4 use abc::{a, bbb, cccccc};
^~~
(internal compiler error: unprintable span)
(internal compiler error: unprintable span)
```
after:
```
x.rs:3 use abc::one_el;
^~~~~~~~~~~
x.rs:4 use abc::{a, bbb, cccccc};
^
x.rs:4 use abc::{a, bbb, cccccc};
^~~
x.rs:4 use abc::{a, bbb, cccccc};
^~~~~~
x.rs:5 use a_very_long_name::{el, el2};
^~
x.rs:5 use a_very_long_name::{el, el2};
^~~
```
Fixes: #33464
Perform name resolution before and during ast->hir lowering
This PR performs name resolution before and during ast->hir lowering instead of in phase 3.
r? @nrc
This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.
[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md
Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.
With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.
Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).
Improve diagnostics for constants being used in irrefutable patterns
It's pretty confusing and this error triggers in resolve only when "shadowing" a const, so let's make that clearer.
r? @steveklabnik
Instead of finding aux-build files in `auxiliary`, we now search for an
`aux` directory relative to the test. So if your test is
`compile-fail/foo.rs`, we would look in `compile-fail/aux`. Similarly,
we ignore the `aux` directory when searching for tets.
Short-cut `T: Sized` trait selection for ADTs
Basically avoids all nested obligations when checking whether an ADT is sized - this speeds up typeck by ~15%
The refactoring fixed#32963, but I also want to make `Copy` not object-safe (will commit that soon).
Fixes#33201
r? @nikomatsakis
This requirement appears to be missing from RFC1214, but is clearly
necessary for translation. The last field of a tuple/enum remains in
a state of limbo, compiling but causing an ICE when it is used - we
should eventually fix that somehow.
this is a [breaking-change] - a soundness fix - and requires a
crater run.
resolve: print location of static for "static in pattern" error
The implementation mirrors the one for "constant defined here" annotation used for constant patterns in the irrefutable-pattern case.
Fixes: #23716
fix various const eval errors
These were found after const_evaluating arbitrary expressions and linting if the const evaluator failed
fixes#33275 (int -> float casts for negative ints)
fixes#33291 (int -> char casts (new! wasn't allowed in constants until this PR))
r? @eddyb
cc @bluss @japaric
typeck: remove confusing suggestion for calling a fn type
* It is not clear what a "base function" is.
* The suggestion just adds parens, so suggests calling without args.
The second point could be fixed with e.g. `(...)` instead of `()`,
but the preceding "note: X is a function, perhaps you wish to call it"
should already be clear enough.
Fixes: #31341
match check: note "catchall" patterns in unreachable error
Caught as catchall patterns are:
* unconditional name bindings
* references to them
* tuple bindings with catchall elements
Fixes#31221.
resolve: improve diagnostics and lay groundwork for resolving before ast->hir
This PR improves diagnostics in `resolve` and lays some groundwork for resolving before ast->hir.
More specifically,
- It removes an API in `resolve` intended for external refactoring tools (see #27493) that appears not to be in active use. The API is incompatible with resolving before ast->hir, but could be rewritten in a more compatible and less intrusive way.
- It improves the diagnostics for pattern bindings that conflict with `const`s.
- It improves the diagnostics for modules used as expressions (fixes#33186).
- It refactors away some uses of the hir map, which is unavavailable before ast->hir lowering.
r? @eddyb
* It is not clear what a "base function" is.
* The suggestion just adds parens, so suggests calling without args.
The second point could be fixed with e.g. `(...)` instead of `()`,
but the preceding "note: X is a function, perhaps you wish to call it"
should already be clear enough.
Fixes: #31341
Feature gate clean
This PR does a bit of cleaning in the feature-gate-handling code of libsyntax. It also fixes two bugs (#32782 and #32648). Changes include:
* Change the way the existing features are declared in `feature_gate.rs`. The array of features and the `Features` struct are now defined together by a single macro. `featureck.py` has been updated accordingly. Note: there are now three different arrays for active, removed and accepted features instead of a single one with a `Status` item to tell wether a feature is active, removed, or accepted. This is mainly due to the way I implemented my macro in the first time and I can switch back to a single array if needed. But an advantage of the way it is now is that when an active feature is used, the parser only searches through the list of active features. It goes through the other arrays only if the feature is not found. I like to think that error checking (in this case, checking that an used feature is active) does not slow down compilation of valid code. :) But this is not very important...
* Feature-gate checking pass now use the `Features` structure instead of looking through a string vector. This should speed them up a bit. The construction of the `Features` struct should be faster too since it is build directly when parsing features instead of calling `has_feature` dozens of times.
* The MacroVisitor pass has been removed, it was mostly useless since the `#[cfg]-stripping` phase happens before (fixes#32648). The features that must actually be checked before expansion are now checked at the time they are used. This also allows us to check attributes that are generated by macro expansion and not visible to MacroVisitor, but are also removed by macro expansion and thus not visible to PostExpansionVisitor either. This fixes#32782. Note that in order for `#[derive_*]` to be feature-gated but still accepted when generated by `#[derive(Trait)]`, I had to do a little bit of trickery with spans that I'm not totally confident into. Please review that part carefully. (It's in `libsyntax_ext/deriving/mod.rs`.)::
Note: this is a [breaking change], since programs with feature-gated attributes on macro-generated macro invocations were not rejected before. For example:
```rust
macro_rules! bar (
() => ()
);
macro_rules! foo (
() => (
#[allow_internal_unstable] //~ ERROR allow_internal_unstable side-steps
bar!();
);
);
```
foo!();
report `const_err` on all expressions that can fail
also a drive-by fix for reporting an "overflow in shift *left*" when shifting an `i64` *right*
This increases the warning noise for shifting by more than the bitwidth and for `-T::MIN`. I can silence the bitwidth warnings explicitly and fix the const evaluator to make sure `--$expr` is treated exactly like `$expr` (which is kinda wrong, but mathematically right).
r? @eddyb
special-case #[derive(Copy, Clone)] with a shallow clone
If a type is Copy then its Clone implementation can be a no-op. Currently `#[derive(Clone)]` generates a deep clone anyway. This can lead to lots of code bloat.
This PR detects the case where Copy and Clone are both being derived (the general case of "is this type Copy" can't be determined by a syntax extension) and generates the shallow Clone impl. Right now this can only be done if there are no type parameters (see https://github.com/rust-lang/rust/issues/31085#issuecomment-178988663), but this restriction can be removed after specialization.
Fixes#31085.
