Regression test for rust-lang/rust#53675.
(Includes a couple variations on the theme. I confirmed that the ones
in `in_expression_position` and `what_if_we_use_panic_directly_in_expr`
both failed back on "rustc 1.30.0-nightly (0f063aef6 2018-09-03)".)
Fix#53675
It is worth pointing out that the reason that so few diagnostics are
effected is because of the filter I put in where it only goes down the
new path if the borrowed place is *not* a prefix of the dropped place.
(Without that filter, a *lot* of the tests would need this change, and
it would probably be a net loss for the UX, since you'd see it even in
cases like borrows of generic types where there is no explicit mention
of `Drop`.)
use structured suggestion for "missing mut" label
Fixes#54133 for both NLL and non-NLL.
r? @estebank
I'm not super happy with the existing wording here, since it's now a suggestion. I wonder if the message would work better as something like "help: make binding mutable: `mut foo`"?
Also, are the `HELP` and `SUGGESTION` comments necessary?
(Includes a couple variations on the theme. I confirmed that the ones
in `in_expression_position` and `what_if_we_use_panic_directly_in_expr`
both failed back on "rustc 1.30.0-nightly (0f063aef6 2018-09-03)".)
resolve: Introduce two sub-namespaces in macro namespace
Two sub-namespaces are introduced in the macro namespace - one for bang macros and one for attribute-like macros (attributes, derives).
"Sub-namespace" means this is not a newly introduced full namespace, the single macro namespace is still in place.
I.e. you still can't define/import two macros with the same name in a single module, `use` imports still import only one name in macro namespace (from any sub-namespace) and not possibly two.
However, when we are searching for a name used in a `!` macro call context (`my_macro!()`) we skip attribute names in scope, and when we are searching for a name used in attribute context (`#[my_macro]`/`#[derive(my_macro)]`) we are skipping bang macro names in scope.
In other words, bang macros cannot shadow attribute macros and vice versa.
For a non-macro analogy, we could e.g. skip non-traits when searching for `MyTrait` in `impl MyTrait for Type { ... }`.
However we do not do it in non-macro namespaces because we don't have practical issues with e.g. non-traits shadowing traits with the same name, but with macros we do, especially after macro modularization.
For `#[test]` and `#[bench]` we have a hack in the compiler right now preventing their shadowing by `macro_rules! test` and similar things. This hack was introduced after making `#[test]`/`#[bench]` built-in macros instead of built-in attributes (https://github.com/rust-lang/rust/pull/53410), something that needed to be done from the start since they are "active" attributes transforming their inputs.
Now they are passed through normal name resolution and can be shadowed, but that's a breaking change, so we have a special hack basically applying this PR for `#[test]` and `#[bench]` only.
Soon all potentially built-in attributes will be passed through normal name resolution (https://github.com/rust-lang/rust/pull/53913) and that uncovers even more cases where the strict "macro namespace is a single namespace" rule needs to be broken.
For example, with strict rules, built-in macro `cfg!(...)` would shadow built-in attribute `#[cfg]` (they are different things), standard library macro `thread_local!(...)` would shadow built-in attribute `#[thread_local]` - both of these cases are covered by special hacks in https://github.com/rust-lang/rust/pull/53913 as well.
Crater run uncovered more cases of attributes being shadowed by user-defined macros (`warn`, `doc`, `main`, even `deprecated`), we cannot add exceptions in the compiler for all of them.
Regressions with user-defined attributes like https://github.com/rust-lang/rust/issues/53583 and https://github.com/rust-lang/rust/issues/53898 also appeared after enabling macro modularization.
People are also usually confused (https://github.com/rust-lang/rust/issues/53205#issuecomment-411552763, https://github.com/rust-lang/rust/issues/53583#issuecomment-415447800) when they see conflicts between attributes and non-attribute macros for the first time.
So my proposed solution is to solve this issue by introducing two sub-namespaces and thus skipping resolutions of the wrong kind and preventing more error-causing cases of shadowing.
Fixes https://github.com/rust-lang/rust/issues/53583
rustc_resolve: don't treat uniform_paths canaries as ambiguities unless they resolve to distinct Def's.
In particular, this allows this pattern that @cramertj mentioned in https://github.com/rust-lang/rust/issues/53130#issuecomment-420848814:
```rust
use log::{debug, log};
fn main() {
use log::{debug, log};
debug!(...);
}
```
The canaries for the inner `use log::...;`, *in the macro namespace*, see the `log` macro imported at the module scope, and the (same) `log` macro, imported in the block scope inside `main`.
Previously, these two possible (macro namspace) `log` resolutions would be considered ambiguous (from a forwards-compat standpoint, where we might make imports aware of block scopes).
With this PR, such a case is allowed *if and only if* all the possible resolutions refer to the same definition (more specifically, because the *same* `log` macro is being imported twice).
This condition subsumes previous (weaker) checks like #54005 and the second commit of #54011.
Only the last commit is the main change, the other two are cleanups.
r? @petrochenkov cc @Centril @joshtriplett
[NLL] Suggest let binding
Closes#49821
Also adds an alternative to `explain_why_borrow_contains_point` that allows changing error messages based on the reason that will be given. This will also be useful for #51026, #51169 and maybe further changes to does not live long enough messages.
Suggest valid crate type if invalid crate type is found
This adds a suggestion to the `invalid_crate_types` lint.
The suggestion is based on the Levenshtein distance to existing crate
types. If no suggestion is found it will show the lint without any
suggestions.
Closes#53958
This adds a suggestion to the `invalid_crate_types` lint.
The suggestion is based on the Levenshtein distance to existing crate
types. If no suggestion is found it will show the lint without any
suggestions.
Add rustc SHA to released DWARF debuginfo
This commit updates the debuginfo that is encoded in all of our released
artifacts by default. Currently it has paths like `/checkout/src/...` but these
are a little inconsistent and have changed over time. This commit instead
attempts to actually define the file paths in our debuginfo to be consistent
between releases.
All debuginfo paths are now intended to be `/rustc/$sha` where `$sha` is the git
sha of the released compiler. Sub-paths are all paths into the git repo at that
`$sha`.
Stabilization change for mod.rs
This change is in response to https://github.com/rust-lang/rust/issues/53125.
The patch makes the feature accepted and removes the tests that tested the
non-accepted status of the feature.
support ascription for patterns in NLL
This implements the strategy outlined in [this comment](https://github.com/rust-lang/rust/issues/47184#issuecomment-416669986):
- We first extend the NLL subtyping code so it can handle inference variables and subtyping.
- Then we extend HAIR patterns with type ascription.
- Then we treat the type `T` in `let pat: T = ...` as an ascription.
Before landing, a few things:
- [x] Fix the WF rule bug (filed a FIXME https://github.com/rust-lang/rust/issues/54105)
- [x] Fix an ICE I encountered locally around bound regions, or else file a follow-up
- [x] More tests probably =)
r? @pnkfelix
stabilize #[used]
closes#40289
RFC for stabilization: rust-lang/rfcs#2386
r? @Centril
Where should this be documented? Currently the documentation is in the unstable book
This commit updates the debuginfo that is encoded in all of our released
artifacts by default. Currently it has paths like `/checkout/src/...` but these
are a little inconsistent and have changed over time. This commit instead
attempts to actually define the file paths in our debuginfo to be consistent
between releases.
All debuginfo paths are now intended to be `/rustc/$sha` where `$sha` is the git
sha of the released compiler. Sub-paths are all paths into the git repo at that
`$sha`.
For some weird reason this fixes `intrinsic-move-val`. It also affects
various test heuristics. I removed one test (`reborrow_basic`) that
didn't seem to really be testing anything in particular anymore,
compared to all the other tests we've got.
rustc_resolve: inject `uniform_paths` canaries regardless of the feature-gate, on Rust 2018.
This PR is an attempt at future-proofing "anchored paths" by emitting the same ambiguity errors that `#![feature(uniform_paths)]` would, with slightly changed phrasing (see added UI tests).
Also, on top of #54005, this PR allows this as well:
```rust
use crate_name;
use crate_name::foo;
```
In that any ambiguity between an extern crate and an import *of that same crate* is ignored.
r? @petrochenkov cc @aturon @Centril @joshtriplett
#53359: putting multiple unresolved import on single line
r? @estebank
Here is WIP implementation of #53359
this PR have clubbed multiple unresolved imports into a single line.
I think still two things need to improve like giving specific `label message` for each span of multi_span(how we can do this?) and second we are getting a warning while compiling, stating something like `E0432` have been passed before.
resolve: Relax shadowing restrictions on macro-expanded macros
Previously any macro-expanded macros weren't allowed to shadow macros from outer scopes.
Now only "more macro-expanded" macros cannot shadow "less macro-expanded" macros.
See comments to `fn may_appear_after` and added tests for more details and examples.
The functional changes are a21f6f588fc28c97533130ae44a6957b579ab58c and 46dd365ce9ca0a6b8653849b80267763c542842a, other commits are refactorings.
Stabilize edition 2018; also updates Clippy, RLS and Cargo
Supersedes https://github.com/rust-lang/rust/pull/53999 , https://github.com/rust-lang/rust/pull/53935
Clippy build was failing there because crate_visibility_modifier feature was taken out of edition 2018 and clippy used it.
The clippy update enables the corresponding feature explicitly.
r? @Mark-Simulacrum
rustc_resolve: only prepend CrateRoot to a non-keyword segment.
Fixes#53770 by treating `use` paths as absolute in a finer-grained manner, specifically:
```rust
use {a, crate::b, self::c, super::d};
```
Used to be interpreted as if it were (when `uniform_paths` is not enabled):
```rust
use ::{a, crate::b, self::c, super::d};
```
With this PR, the `CrateRoot` pseudo-keyword indicating an absolute path is only inserted when the first path segment is found (if it's not a keyword), i.e. the example behaves like:
```rust
use {::a, crate::b, self::c, super::d};
```
This should (finally) make `use {path};` fully equivalent to `use path;`.
r? @petrochenkov cc @cramertj @joshtriplett @nikomatsakis
This change is in response to https://github.com/rust-lang/rust/issues/53125.
The patch makes the feature accepted and removes the tests that tested the
non-accepted status of the feature.
Rollup of 10 pull requests
Successful merges:
- #53315 (use `NonZeroU32` in `newtype_index!`macro, change syntax)
- #53932 ([NLL] Remove base_place)
- #53942 (Rewrite `precompute_borrows_out_of_scope` for fewer hash table lookups.)
- #53973 (Have rust-lldb look for the rust-enabled lldb)
- #53981 (Implement initializer() for FileDesc)
- #53987 (rustbuild: allow configuring llvm version suffix)
- #53993 (rustc_resolve: don't record uniform_paths canaries as reexports.)
- #54007 (crates that provide a `panic_handler` are exempt from the `unused_extern_crates` lint)
- #54040 (update books for next release)
- #54050 (Update `petgraph` dependency to 0.4.13 to fix build with nightly)
[NLL] Remove base_place
This function was supposed to make `Box` less special. But
* I think that the consensus is that MIR borrowck is going to fully special case `Box`
* It wasn't implemented correctly, it's looking at the type of the wrong `Place`, resulting in weird behaviour:
```rust
#![feature(nll)]
type A = Box<i32>; // If this is changed to another type then this will compile.
pub fn foo(x: Box<(String, A)>) {
let a = x.0; // This will compile if these lines are swapped
let b = x.1;
}
```
r? @nikomatsakis
stabilize #[panic_handler]
closes#44489
### Update(2018-09-07)
This was proposed for stabilization in https://github.com/rust-lang/rust/issues/44489#issuecomment-398965881 and its FCP with disposition to merge / accept is nearly over. The summary of what's being stabilized can be found in https://github.com/rust-lang/rust/issues/44489#issuecomment-416645946
Documentation PRs:
- Reference. https://github.com/rust-lang-nursery/reference/pull/362
- Nomicon. https://github.com/rust-lang-nursery/nomicon/pull/75
---
`#[panic_implementation]` was implemented recently in #50338. `#[panic_implementation]` is basically the old `panic_fmt` language item but in a less error prone (\*) shape. There are still some issues and questions to sort out around this feature (cf. #44489) but this PR is meant to start a discussion about those issues / questions with the language team.
(\*) `panic_fmt` was not type checked; changes in its function signature caused serious, silent binary size regressions like the one observed in #43054
Some unresolved questions from #44489:
> Should the Display of PanicInfo format the panic information as "panicked at 'reason',
> src/main.rs:27:4", as "'reason', src/main.rs:27:4", or simply as "reason".
The current implementation formats `PanicInfo` as the first alternative, which is how panic messages are formatted by the `std` panic handler. The `Display` implementation is more than a convenience: `PanicInfo.message` is unstable so it's not possible to replicate the `Display` implementation on stable.
> Is this design compatible, or can it be extended to work, with unwinding implementations for
> no-std environments?
I believe @whitequark made more progress with unwinding in no-std since their last comment in #44489. Perhaps they can give us an update?
---
Another unresolved question is where this feature should be documented. The feature currently doesn't have any documentation.
cc @rust-lang/lang
cc @jackpot51 @alevy @phil-opp
This allows it to print out the "late-bound regions" from the closure
context more easily. Besides, all the state that is being printed it
is private to the `UniversalRegions`.
[nll] teach SCC about `'static`
r? @nikomatsakis
I think this is right? I am seeing better performance on the `html5ever` benchmark but I'd like a perf run to quantify the exact speedup. There's a few ui tests failing due to changes in the error messages. The main issue seems to be that returns aren't being detected correctly?
`mir_check_cast_unsize.rs` before:
```
error: unsatisfied lifetime constraints
--> mir_check_cast_unsize.rs:17:46
|
17 | fn bar<'a>(x: &'a u32) -> &'static dyn Debug {
| ________--____________________________________^
| | |
| | lifetime `'a` defined here
18 | | //~^ ERROR unsatisfied lifetime constraints
19 | | x
20 | | //~^ WARNING not reporting region error due to nll
21 | | }
| |_^ return requires that `'a` must outlive `'static`
```
`mir_check_cast_unsize.rs` after:
```
error: unsatisfied lifetime constraints
--> mir_check_cast_unsize.rs:19:5
|
17 | fn bar<'a>(x: &'a u32) -> &'static dyn Debug {
| -- lifetime `'a` defined here
18 | //~^ ERROR unsatisfied lifetime constraints
19 | x
| ^ cast requires that `'a` must outlive `'static`
```
Rollup of 17 pull requests
Successful merges:
- #53299 (Updated core/macros.rs to note it works in a no_std environment.)
- #53376 (Cross reference io::copy and fs::copy in docs.)
- #53455 (Individual docs for {from,to}_*_bytes)
- #53550 (librustc_lint: In recursion warning, change 'recurring' to 'recursing')
- #53860 (Migrate (some) of run-pass/ to ui)
- #53874 (Implement Unpin for Box, Rc, and Arc)
- #53895 (tidy: Cleanups and clippy warning fixes)
- #53946 (Clarify `ManuallyDrop` docs)
- #53948 (Minimized clippy test from when NLL disabled two-phase borrows)
- #53959 (Add .git extension to submodule paths missing it)
- #53966 (A few cleanups and minor improvements to mir/dataflow)
- #53967 (propagate build.python into cmake)
- #53979 (Remove `#[repr(transparent)]` from atomics)
- #53991 (Add unchecked_shl/shr check for intrinsics to fix miri's test suit)
- #53992 (migrate run-pass/borrowck to ui/run-pass)
- #53994 (migrate run-pass/*/ to ui/run-pass)
- #54023 (update clippy submodule)
Migrate (some) of run-pass/ to ui
This is a step towards addressing #53764. Much still remains.
I went through a large portion of the `*.rs` files that were directly stored into `src/test/run-pass/` and moved them into various subdirectories of a newly created `src/test/ui/run-pass/`.
(yes, it would have perhaps been nice to meld it more directly with directories already in `src/test/ui/`; but the sad truth is that opens up the reality of filename collisions, and one of my short term goals for resolving #53764 is to keep the *filenames* invariant, even as their parents directories and contents are mildly revised...)
librustc_lint: In recursion warning, change 'recurring' to 'recursing'
The existing wording seems incorrect.
Aside: This warning, 'function cannot return without recursing' is not perfectly clear - it implies that the function _can_ return, it's just got to recurse. But really the fn cannot return period. Clearer wording: 'function recurses infinitely; it cannot return'; or 'function is infinitely self-recursive; it cannot return, and this is probably an error'. I like that.
rustc_resolve: allow `use crate_name;` under `uniform_paths`.
Specifically, `use crate_name;` and `use crate_name::{self, ...};` are now allowed, whereas previously there would produce a (false positive) ambiguity error, as the ambiguity detection code was seeing the `crate_name` import as a locally-available definition to conflict with the crate.
r? @petrochenkov cc @aturon @joshtriplett @Centril
Don't reduce E0161 to a warning in NLL migrate mode
This error has been on stable for a while, and allowing such code cause the compile to later ICE (since we can't codegen it). Errors `box UNSIZED EXPR` with unsized locals because it's not compatible with the current evaluation order (create the box before evaluating the expressions).
cc #53469 (fixes the ICE in this case)
cc @qnighy
Fix issue #52475: Make loop detector only consider reachable memory
As [suggested](https://github.com/rust-lang/rust/pull/51702#discussion_r197585664) by @oli-obk `alloc_id`s should be ignored by traversing all `Allocation`s in interpreter memory at a given moment in time, beginning by `ByRef` locals in the stack.
- [x] Generalize the implementation of `Hash` for `EvalSnapshot` to traverse `Allocation`s
- [x] Generalize the implementation of `PartialEq` for `EvalSnapshot` to traverse `Allocation`s
- [x] Commit regression tests
Fixes#52626
Fixes https://github.com/rust-lang/rust/issues/52849
That is, opting to ignore stable `#![feature(..)]`, under my theory
that a reviewer would prefer as much stuff to be bucketed under "ah
another `#![allow(..)]` here." as possible.
that is, I suspect it should be retired because it is testing behavior
(namely a `#[repr(C)] struct Empty;`) that, if I understand correctly,
is undefined.
See also rust-lang/rust#53859.
rustc_typeck: turn `where Type:,` into a WF(Type) predicate, instead of ignoring it.
Fixes#53696, assuming crater doesn't catch anyone using this syntax already.
Allowing an empty list of bounds in the grammar was done for the benefit of macro authors, most of which would *probably* be using it for bounds on type parameters, which are always WF.
r? @nikomatsakis cc @petrochenkov
* When encountering EOF, point at the last opening brace that does not
have the same indentation level as its close delimiter.
* When encountering the wrong type of close delimiter, point at the
likely correct open delimiter to give a better idea of what went
wrong.
Various small diagnostic and code clean up
- Point at def span on incorrect `panic` or `oom` function
- Use structured suggestion instead of note for `+=` that can be performed on a dereference of the left binding
- Small code formatting cleanup
set cfg(rustdoc) when rustdoc is running on a crate
When using `#[doc(cfg)]` to document platform-specific items, it's a little cumbersome to get all the platforms' items to appear all at once. For example, the standard library adds `--cfg dox` to rustdoc's command line whenever it builds docs, and the documentation for `#![feature(doc_cfg)]` suggests using a Cargo feature to approximate the same thing. This is a little awkward, because you always need to remember to set `--features dox` whenever you build documentation.
This PR proposes making rustdoc set `#[cfg(rustdoc)]` whenever it runs on a crate, to provide an officially-sanctioned version of this that is set automatically. This way, there's a standardized way to declare that a certain version of an item is specifically when building docs.
To try to prevent the spread of this feature from happening too quickly, this PR also restricts the use of this flag to whenever `#![feature(doc_cfg)]` is active. I'm sure there are other uses for this, but right now i'm tying it to this feature. (If it makes more sense to give this its own feature, i can easily do that.)
Implement the `min_const_fn` feature gate
cc @RalfJung @eddyb
r? @Centril
implements the feature gate for #53555
I added a hack so the `const_fn` feature gate also enables the `min_const_fn` feature gate. This ensures that nightly users of `const_fn` don't have to touch their code at all.
The `min_const_fn` checks are run first, and if they succeeded, the `const_fn` checks are run additionally to ensure we didn't miss anything.
With eRFC 2497, previously accepted ambigious syntax regarding use of
`&&` and `||` in if-let and while-let statements should now warn
or error depending on the edition.
This commit takes a naive approach to detecting ambigious use of `&&`
or `||` and will probably need fine tuned to handle all cases.
Fix promotion stability hole in old borrowck
r? @nikomatsakis
I screwed up the promotion stability checks. Big time. They were basically nonexistant. We had tests for it. I also screwed up said tests. This is in stable already :(
Basically stability checks of promotion only worked if you tried to use a const fn defined in the same crate.
cc @eddyb
Generalize `async_idents` to all new keywords
This commit generalizes the existing `async_idents` lint to easily encompass
other identifiers that will be keywords in future editions. The new lint is
called `keyword_idents` and the old `async_idents` lint is registered as renamed
to this new lint.
As a proof of concept the `try` keyword was added to this list as it looks to be
listed as a keyword in the 2018 edition only. The `await` keyword was not added
as it's not listed as a keyword yet.
Closes#53077
This commit generalizes the existing `async_idents` lint to easily encompass
other identifiers that will be keywords in future editions. The new lint is
called `keyword_idents` and the old `async_idents` lint is registered as renamed
to this new lint.
As a proof of concept the `try` keyword was added to this list as it looks to be
listed as a keyword in the 2018 edition only. The `await` keyword was not added
as it's not listed as a keyword yet.
Closes#53077
rustc: Suggest removing `extern crate` in 2018
This commit updates the `unused_extern_crates` lint to make automatic
suggestions about removing `extern crate` annotations in the 2018 edition. This
ended up being a little easier than originally though due to what's likely been
fixed issues in the resolver!
Closes#52829
Miri engine cleanup
* Unify the two maps in memory to store the allocation and its kind together.
* Share the handling of statics between CTFE and miri: The miri engine always
uses "lazy" `AllocType::Static` when encountering a static. Acessing that
static invokes CTFE (no matter the machine). The machine only has any
influence when writing to a static, which CTFE outright rejects (but miri
makes a copy-on-write).
* Add an `AllocId` to by-ref consts so miri can use them as operands without
making copies.
* Move responsibilities around for the `eval_fn_call` machine hook: The hook
just has to find the MIR (or entirely take care of everything); pushing the
new stack frame is taken care of by the miri engine.
* Expose the intrinsics and lang items implemented by CTFE so miri does not
have to reimplement them.
* Allow Machine to hook into foreign statics (used by miri to get rid of some other hacks).
* Clean up function calling.
* Switch const sanity check to work on operands, not mplaces.
* Move const_eval out of rustc_mir::interpret, to make sure that it does not access private implementation details.
In particular, we can finally make `eval_operand` take `&self`. :-)
Should be merged after https://github.com/rust-lang/rust/pull/53609, across which I will rebase.
Warn on anon params in 2015 edition
cc #41686https://github.com/rust-lang/rfcs/pull/2522
cc @Centril @nikomatsakis
TODO:
- [x] Make sure the tests pass.
- [x] Make sure there is rustfix-able suggestion. Current plan is to just suggest `_ : Foo`
- [x] Add a rustfix ui test.
EDIT: It seems I already did the last two in #48309
resolve suggestions should use `crate::` when enabled
I couldn't find a way to add a specific assertion for the ui test, so the expected output is living under the `crates-in-path.stderr` ui test.
- is this the right place for the test?
fixes#51212
This commit updates the `unused_extern_crates` lint to make automatic
suggestions about removing `extern crate` annotations in the 2018 edition. This
ended up being a little easier than originally though due to what's likely been
fixed issues in the resolver!
Closes#52829
fix NLL ICEs
Custom type-ops reuse some of the query machinery -- but while query results are canonicalized after they are constructed, custom type ops are not, and hence we have to resolve the type variables to avoid an ICE here.
Also, use the type-op machinery for implied outlives bounds.
Fixes#53568Fixes#52992Fixes#53680
In investigating [an issue][1] with `panic_implementation` defined in an
executable that's optimized I once again got to rethinking a bit about the
`rustc_std_internal_symbol` attribute as well as weak lang items. We've sort of
been non-stop tweaking these items ever since their inception, and this
continues to the trend.
The crux of the bug was that in the reachability we have a [different branch][2]
for non-library builds which meant that weak lang items (and std internal
symbols) weren't considered reachable, causing them to get eliminiated by
ThinLTO passes. The fix was to basically tweak that branch to consider these
symbols to ensure that they're propagated all the way to the linker.
Along the way I've attempted to erode the distinction between std internal
symbols and weak lang items by having weak lang items automatically configure
fields of `CodegenFnAttrs`. That way most code no longer even considers weak
lang items and they're simply considered normal functions with attributes about
the ABI.
In the end this fixes the final comment of #51342
[1]: https://github.com/rust-lang/rust/issues/51342#issuecomment-414368019
[2]: 35bf1ae257/src/librustc/middle/reachable.rs (L225-L238)
Remove anonymous trait params from 2018 and beyond
cc @Centril @nikomatsakis
cc #41686rust-lang/rfcs#2522#53272
This PR removes support for anonymous trait parameters syntactically in rust 2018 and onward.
TODO:
- [x] Add tests
Fix#53525 - Unify E0243, E0244, E0087, E0088, E0089, and E0090 into E0107
Fix#53525
This pr merges all errors related to too many or too few generic arguments in types and functions. E0243, E0244, E0087, E0088, E0089, E0090 errors will no longer be emitted and E0107 will be used instead.
MIR: support user-given type annotations on fns, structs, and enums
This branch adds tooling to track user-given type annotations on functions, structs, and enum variant expressions. The user-given types are passed onto NLL which then enforces them.
cc #47184 — not a complete fix, as there are more cases to cover
r? @eddyb
cc @rust-lang/wg-compiler-nll
Fix compile panic on non existent type return
Reverted the change 28a76a9000 (diff-4ed25c00aceb84666fca639cf8101c7cL1069) which was panicking when returning a type that cannot be found in the current scope and added testing for the compile error.
For example:
```rust
fn addition() -> Wrapper<impl A> {}
```
Where Wrapper is undefined in the scope.
