| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This pass causes mis-optimizations in some cases and is probably no
longer really important for us, so let's disable it for now.
Fixes #30081
|
|
|
|
|
|
expansion already by growing the RHS to be bigger than LHS (all the way
to `'static` if necessary). This is needed because contraction doesn't
handle givens. Fixes #28934.
|
|
|
|
Fixes #21546.
|
|
this has the funky side-effect of also allowing constant evaluation of function calls to functions that are not `const fn` as long as `check_const` didn't mark that function `NOT_CONST`
It's still not possible to call a normal function from a `const fn`, but let statements' initialization value can get const evaluated (this caused the fallout in the overflowing tests)
we can now do this:
```rust
const fn add(x: usize, y: usize) -> usize { x + y }
const ARR: [i32; add(1, 2)] = [5, 6, 7];
```
also added a test for destructuring in const fn args
```rust
const fn i((a, b): (u32, u32)) -> u32 { a + b } //~ ERROR: E0022
```
This is a **[breaking change]**, since it turns some runtime panics into compile-time errors. This statement is true for ANY improvement to the const evaluator.
|
|
These commits revert https://github.com/rust-lang/rust/pull/28504 and add a regression test pointed out by @petrochenkov, it's not immediately clear with the regression that the accessibility check should be removed, so for now preserve the behavior on stable by default.
r? @nrc
|
|
r=nikomatsakis
This PR switches the implemented ordering from `unsafe const fn` (as was in the original RFC) to `const unsafe fn` (which is what the lang team decided on)
|
|
This reverts commit f4f95eb3a9f2c3c38679db84aabbb7cdb46d2641.
|
|
Closes #21410.
Closes #24972.
|
|
Closes #21410.
Closes #24972.
|
|
Closes #22781.
Closes #23891.
Closes #24956.
Closes #25145.
Closes #25693.
Closes #26095.
Closes #26459.
Closes #27320.
Closes #27895.
|
|
Closes #28189
|
|
Closes #22781.
Closes #23891.
Closes #24956.
Closes #25145.
Closes #25693.
Closes #26095.
Closes #26459.
Closes #27320.
Closes #27895.
|
|
|
|
|
|
Closes #22403.
|
|
|
|
Currently it is possible to do the following:
- define a module named `Foo` and then a unit or tuple struct also named `Foo`
- define any struct named `Foo` and then a module named `Foo`
This commit introduces a warning for both of these cases.
|
|
trait definitions, and give prefence to the former. This is consistent
with what we do for selection. It also works around a limitation
that was leading to #28871.
|
|
Closes #28936.
|
|
Add dropck unsafe escape hatch (UGEH) to vec::IntoIter.
Fix #29166
|
|
Closes https://github.com/rust-lang/rust/issues/29145
[breaking-change], needs a crater run.
|
|
Fix #29166
|
|
This is a WIP PR for my implementation of drain over the VecDeque data structure supporting ranges. It brings the VecDeque drain implementation in line with Vec's.
Tests haven't been written for the new function yet.
|
|
|
|
|
|
This PR turns statically known erroneous code (e.g. numeric overflow) into a warning and continues normal code-generation to emit the same code that would have been generated without `check_const` detecting that the result can be computed at compile-time.
<del>It's not done yet, as I don't know how to properly emit a lint from trans. I can't seem to extract the real lint level of the item the erroneous expression is in.</del> It's an unconditional warning now.
r? @pnkfelix
cc @nikomatsakis
* [RFC 1229 text](https://github.com/rust-lang/rfcs/blob/master/text/1229-compile-time-asserts.md)
* RFC PR: rust-lang/rfcs#1229
* tracking issue: https://github.com/rust-lang/rust/issues/28238
|
|
Closes #27105.
|
|
Closes #27105.
|
|
This change has two consequences:
1. It makes `Arc<T>` and `Rc<T>` covariant in `T`.
2. It causes the compiler to reject code that was unsound with respect
to dropck. See compile-fail/issue-29106.rs for an example of code that
no longer compiles. Because of this, this is a [breaking-change].
Fixes #29037.
Fixes #29106.
|
|
This is a [breaking change].
@brson could you do a Crater run with this PR please?
Lets not land till Crater says its OK.
This was discussed at https://internals.rust-lang.org/t/does-anyone-use-the-push-pop-unsafe-macros/2702
|
|
Fixes #28676.
There doesn't seem to be a good way to add a test for this, but I tested the repro in #28676 and confirmed it now yields the correct result.
|
|
|
|
This is needed as item types are allowed to be unnormalized.
Fixes an ICE that occurs when foreign function signatures contained
an associated type.
Fixes #28983
|
|
This is the original test implementation, which works according to the tests I wrote, but might need a review.
|
|
This rather crucial requirement was not checked. In most cases, that
didn't cause any trouble because the argument types are required to
outlive the call and are subtypes of a subformula of the callee type.
However, binary ops are taken by ref only indirectly, without it being
marked in the argument types, which led to the argument types not being
constrained anywhere causing spurious errors (as these are basically
unconstrainable, I don't think this change can break code). Of course,
the old way was also incorrent with contravariance, but that is still
unsound for other reasons.
This also improves rustc::front to get RUST_LOG to *somewhat* work.
Fixes #28999. That issue is one of the several regression introduced by #28669.
r? @pnkfelix
|
|
Closes #22814
|
|
const eval errors outside of true constant enviroments are not reported anymore, but instead forwarded to a lint.
|
|
|
|
This rather crucial requirement was not checked. In most cases, that
didn't cause any trouble because the argument types are required to
outlive the call and are subtypes of a subformula of the callee type.
However, binary ops are taken by ref only indirectly, without it being
marked in the argument types, which led to the argument types not being
constrained anywhere causing spurious errors (as these are basically
unconstrainable, I don't think this change can break code). Of course,
the old way was also incorrent with contravariance, but that is still
unsound for other reasons.
This also improves rustc::front to get RUST_LOG to *somewhat* work.
Fixes #28999
|
|
Closes #22814
|
|
This is needed as item types are allowed to be unnormalized.
Fixes an ICE that occurs when foreign function signatures contained
an associated type.
Fixes #28983
|
|
Closes #17336
|
|
This is a [breaking change].
|
|
Here is my attempt to resolve issue #28822, @Manishearth.
Please let me know if it's fine. And if not, what should I do instead?
This issue felt like quite a good start for some rust contributions. It allows me to get used to the workflow and codebase of rust in an easy-to-swallow manner. Are there any other issues you would recommend me to look at? :) Would love to do some more stuff!
|
|
|
|
implement RFC 1238: nonparametric dropck.
cc #28498
cc @nikomatsakis
|
|
Major revision to the dropck_legal_cycles test.
1. Added big comment block explaining the test framework.
2. Added tests exericising Rc and Arc. This was inspired by a comment
from eefriedman on PR #28861.
3. Made the cycle-detection not issue false-positives on acyclic dags.
Doing this efficiently required revising the framework; instead of
visiting all children (i.e. doing a traversal), now each test is
responsible for supplying the path that will act as a witness to
the cycle.
Luckily for me, all of the pre-existing tests worked with a trivial
path built from "always tke your first left", but new tests I added
did require other input paths (i.e., "first turn right, then left".
(The path representation is a bit-string and its branches are
n-ary, not word phrases and binary branches as you might think
from the outline above.)
cc PR #27185
|
