| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
After #26694, the overloaded operator and "impl not known at method lookup time" cases started triggering the lint.
I've also added checks for overloaded autoderef and method calls via paths (i.e. `T::method()`).
All new 8 test cases did not trigger the lint before #26694.
r? @huonw
|
|
|
|
After this change, the only remaining symbol we are pulling from libgcc on Win64 is `__chkstk_ms` - the stack probing routine.
|
|
|
|
There are still problems in both the design and implementation of this, so we don't want it landing in 1.2.
cc @arielb1 @nikomatsakis
cc #27364
r? @alexcrichton
|
|
|
|
|
|
There are multiple issues with them as designed and implemented.
cc #27364
|
|
This also calls the right API, which e.g. prevents a suggestion
for #![feature(unboxed_closures)] on stable.
Fixes #26970
r? @steveklabnik
|
|
Improves diagnostics in various locations, namely:
* A few error messages that orignally were a mix of an error message and suggestion how to fix it have been split up into two messages: an error and help/hint.
* Never report “illegal”. Fixes https://github.com/rust-lang/rust/issues/27288
|
|
Fixes #27033
Fixes #27077
r? @alexcrichton
|
|
This fixes multiple bugs, and as several of these are soundness issue, is a [breaking-change].
r? @pnkfelix
|
|
This commit is an implementation of [RFC 1193][rfc] which adds the ability to
the compiler to cap the lint level for the entire compilation session. This flag
will ensure that no lints will go above this level, and Cargo will primarily use
this flag passing `--cap-lints allow` to all upstream dependencies.
[rfc]: https://github.com/rust-lang/rfcs/pull/1193
Closes #27259
|
|
This commit is an implementation of [RFC 1193][rfc] which adds the ability to
the compiler to cap the lint level for the entire compilation session. This flag
will ensure that no lints will go above this level, and Cargo will primarily use
this flag passing `--cap-lints allow` to all upstream dependencies.
[rfc]: https://github.com/rust-lang/rfcs/pull/1193
Closes #27259
|
|
|
|
Mostly by splitting error messages into proper pairs of errors and helps
|
|
|
|
as this breaks code that worked under some conditions, this is a
[breaking-change]
Fixes #27033
Fixes #27077
|
|
This also calls the right API, which e.g. prevents a suggestion
for #![feature(unboxed_closures)] on stable.
Fixes #26970
|
|
FreeBSD i386 snapshot is missing, failed tests (possibly spurious).
r? @alexcrichton
|
|
|
|
Fixes issue #27302.
|
|
Fixes issue #27302.
|
|
|
|
|
|
|
|
|
|
This patch allows type parameter defaults to influence type inference. This is a possible breaking change since it effects the way type inference works and will have different behavior when mixing defaults and literal fallback.
|
|
***Edit: Fixed now.*** I'm pretty sure the way I'm using LLVMReplaceAllUsesWith here is
unsafe... but before I figure out how to fix that, I'd like a
reality-check: is this actually useful?
|
|
This introduces a test for #23389 and improves the error behaviour to treat the malformed LHS as an error, not a compiler bug.
The parse phase that precedes the call to `check_lhs_nt_follows` could possibly be enhanced to police the format itself (which the old code suggests was the original intention), but I'm not sure that's any nicer than just parsing the matcher as generic rust code and then policing the specific requirements for being a macro matcher afterwards (as this does).
Fixes #23389
|
|
The borrow checker doesn't allow constructing such a type at runtime
using safe code, but there isn't any reason to ban them in the type checker.
Included in this commit is an example of a neat static doubly-linked list.
Feature-gated under the static_recursion gate to be on the safe side, but
there are unlikely to be any reasons this shouldn't be turned on by
default.
|
|
|
|
There isn't any particularly good reason for this restriction, so just
get rid of it, and fix trans to handle this case.
|
|
This fixes a few soundness bugs in dropck, so to anyone who relied on them,
this is a
[breaking-change]
Fixes #24086.
Fixes #25389.
Fixes #25598.
Fixes #25750.
Fixes #26641.
Fixes #26657.
Fixes #27240.
Fixes #27241.
|
|
- Successful merges: #27137, #27145, #27177, #27193, #27212, #27220, #27229, #27235, #27238, #27244, #27251
- Failed merges:
|
|
Hi all.
This is my first contribution to Rust and fixes an issue causing an invalid error message to be presented to the user when using unit struct as length of a repeat expression, issue #27008. The solution is based on suggestions by @oli-obk, but as I'm a complete newbie to this, I have no clue if I got them right :)
The biggest concern I have is that if the `NodeId` I'm returning is the correct one or not (it's not meaningful in this case but I think it would be nice to get it right).
|
|
Refactors the "desugaring" of closures to expose the types of the upvars. This is necessary to be faithful with how actual structs work. The reasoning of the particular desugaring that I chose is explained in a fairly detailed comment.
As a side-effect, recursive closure types are prohibited unless a trait object intermediary is used. This fixes #25954 and also eliminates concerns about unrepresentable closure types that have infinite size, I believe. I don't believe this can cause regressions because of #25954.
(As for motivation, besides #25954 etc, this work is also intended as refactoring in support of incremental compilation, since closures are one of the thornier cases encountered when attempting to split node-ids into item-ids and within-item-ids. The goal is to eliminate the "internal def-id" distinction in astdecoding. However, I have to do more work on trans to really make progress there.)
r? @nrc
|
|
Macro desugaring of `in PLACE { BLOCK }` into "simpler" expressions following the in-development "Placer" protocol.
Includes Placer API that one can override to integrate support for `in` into one's own type. (See [RFC 809].)
[RFC 809]: https://github.com/rust-lang/rfcs/blob/master/text/0809-box-and-in-for-stdlib.md
Part of #22181
Replaced PR #26180.
Turns on the `in PLACE { BLOCK }` syntax, while leaving in support for the old `box (PLACE) EXPR` syntax (since we need to support that at least until we have a snapshot with support for `in PLACE { BLOCK }`.
(Note that we are not 100% committed to the `in PLACE { BLOCK }` syntax. In particular I still want to play around with some other alternatives. Still, I want to get the fundamental framework for the protocol landed so we can play with implementing it for non `Box` types.)
----
Also, this PR leaves out support for desugaring-based `box EXPR`. We will hopefully land that in the future, but for the short term there are type-inference issues injected by that change that we want to resolve separately.
|
|
|
|
impossible.
|
|
upvars after analysis is done. Remove the `closure_upvars` helper and
just consult this list of type variables directly.
|
|
Makes the lint a bit more accurate, and improves the quality of the diagnostic
messages by explicitly returning an error message.
|
|
|
|
|
|
Makes the lint a bit more accurate, and improves the quality of the diagnostic
messages by explicitly returning an error message.
The new lint is also a little more aggressive: specifically, it now
rejects tuples, and it recurses into function pointers.
|
|
saturated to checked arith.
|
|
unit-struct path expressions. Fixes #27008
|
|
Pretty straightforward; just need to make sure to explicitly handle
the generic parameters of each ast::ForeignItemFn.
Fixes #26587.
|
|
|
