- 21 10月, 2018 4 次提交
-
-
由 Matthew Jasper 提交于
This gives at least some explanation for why a borrow is expected to last for a certain free region. Also: * Reports E0373: "closure may outlive the current function" with NLL. * Special cases the case of returning a reference to (or value referencing) a local variable or temporary (E0515). * Special case assigning a reference to a local variable in a closure to a captured variable.
-
由 Matthew Jasper 提交于
-
由 Matthew Jasper 提交于
Adds UseAsConst and UseAsStatic to replace Return in consts/statics. Don't report the arguments to an overloaded operator as CallArguments. Also don't report "escaping data" in these items.
-
由 Matthew Jasper 提交于
-
- 20 10月, 2018 8 次提交
-
-
由 bors 提交于
Allow explicit matches on ! without warning It's now possible to explicitly match on `!` without an unreachable code warning. This seems desirable as promoting explicitness. Fixes https://github.com/rust-lang/rust/issues/55116.
-
由 bors 提交于
Prefer unwrap_or_else to unwrap_or in case of function calls/allocations The contents of `unwrap_or` are evaluated eagerly, so it's not a good pick in case of function calls and allocations. This PR also changes a few `unwrap_or`s with `unwrap_or_default`. An added bonus is that in some cases this change also reveals if the object it's called on is an `Option` or a `Result` (based on whether the closure takes an argument).
-
由 bors 提交于
Deprecate the `FxHashMap()` and `FxHashSet()` constructor function hack
-
由 bors 提交于
Help suggests non-existent package std::os::ext::process::CommandExt Fixes #39175.
-
由 bors 提交于
handle underscore bounds in unexpected places Per the discussion on #54902, I made it a hard error to use lifetime bounds in various places where they used to be permitted: - `where Foo: Bar<'_>` for example I also moved error reporting to HIR lowering and added `Error` variants to let us suppress downstream errors that result. I (imo) improved the error message wording to be clearer, as well. In the process, I fixed the ICE in #52098. Fixes #54902 Fixes #52098
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 bors 提交于
support type annot in constants, casts Fixes #54571 Fixes #54332 Fixes #55183 r? @pnkfelix
-
- 19 10月, 2018 28 次提交
-
-
由 David Wood 提交于
In order to output a path that could actually be imported (valid and visible), we need to handle re-exports correctly. For example, take `std::os::unix::process::CommandExt`, this trait is actually defined at `std::sys::unix::ext::process::CommandExt` (at time of writing). `std::os::unix` rexports the contents of `std::sys::unix::ext`. `std::sys` is private so the "true" path to `CommandExt` isn't accessible. In this case, the visible parent map will look something like this: (child) -> (parent) `std::sys::unix::ext::process::CommandExt` -> `std::sys::unix::ext::process` `std::sys::unix::ext::process` -> `std::sys::unix::ext` `std::sys::unix::ext` -> `std::os` This is correct, as the visible parent of `std::sys::unix::ext` is in fact `std::os`. When printing the path to `CommandExt` and looking at the current segment that corresponds to `std::sys::unix::ext`, we would normally print `ext` and then go to the parent - resulting in a mangled path like `std::os::ext::process::CommandExt`. Instead, we must detect that there was a re-export and instead print `unix` (which is the name `std::sys::unix::ext` was re-exported as in `std::os`).
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
This can trigger more errors than before. Not sure what is the best fix here.
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
Also, avoid shadowing of the `ty` variable by giving the `cast_ty` and `var_ty` variables different names. We want to get the user-provided type from `cast_ty.hir_id`.
-
由 Keith Yeung 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
Also include a test that was not working previously.
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
It's really layered atop the core "relate-types" code
-
由 Oliver Scherer 提交于
-
由 Oliver Scherer 提交于
-
由 Oliver Scherer 提交于
-
由 Oliver Scherer 提交于
-
由 Oliver Scherer 提交于
-
由 Oliver Scherer 提交于
-
由 Oliver Scherer 提交于
-
由 Oliver Scherer 提交于
-
由 Oliver Scherer 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-