| 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.
|
|
|
|
|
|
empty region, and they complicate region inference to no particular end.
They also lead in some cases to spurious errors like #29048 (though in
some cases these errors are helpful in tracking down missing
constraints).
|
|
|
|
Although the compiler itself does not depend on this DLL the `libstdc++-6.dll`
that we're shipping does, so we still need to include it.
|
|
`as_local_node_id`, instead just compare against `Some(id)`.
Fixes #29161.
|
|
|
|
Change error reporting of conflicting loans to stop earlier after printing
an error for a given borrow, instead of proceeding to error on possibly every
issued loan. This keeps us down to O(n) errors (for n problem lines), instead
of O(n^2) errors in some cases.
Fixes #27485.
|
|
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.
|
|
Fix #24114.
|
|
The beginning of the work that needs to be done as part of #28835.
:sunny:
|
|
So we cannot assume that the function call was marked NOT_CONST by check_const.
|
|
Rust reference is a bit confusing here, because it does not explicitly mention trait objects.
See an example of confusion here https://users.rust-lang.org/t/confusion-about-impls-without-for/3379/2 :)
r? @steveklabnik
|
|
As displayed before this commit, I found the book confusing in its
explanation of `#`-led comments in `rust` blocks. Possibly the
biggest confusion was because the many-dashes construct does not
become an HR element in the Markdown translator used, so things were
not being properly set off.
This change should more clearly show the as-rendered content as
rendered, and the as-coded content as code.
|
|
|
|
This makes it easier to tell which thread does how much work. Output now looks like this:
```
time: 0.000; rss: 55MB llvm function passes [0]
time: 0.000; rss: 55MB llvm function passes [2]
time: 0.000; rss: 55MB llvm function passes [1]
time: 0.000; rss: 55MB llvm module passes [0]
time: 0.000; rss: 55MB llvm module passes [1]
time: 0.000; rss: 55MB llvm module passes [2]
time: 0.000; rss: 55MB llvm function passes [3]
time: 0.000; rss: 55MB llvm module passes [3]
time: 0.000; rss: 55MB codegen passes [1]
time: 0.000; rss: 55MB codegen passes [2]
time: 0.000; rss: 55MB codegen passes [0]
time: 0.000; rss: 56MB codegen passes [1]
time: 0.001; rss: 56MB codegen passes [3]
```
|
|
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
|
|
I didn't see anything particularly weird here. The last commit has the only changes I'm not 100% sure about.
I ignored tables.rs since it's genrated, but I updated the python script that generates it.
?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)
|
|
|
|
|
|
|
|
Previously, if you copied a signature from a trait definition such as:
```rust
fn foo<'a>(&'a Bar) -> bool {}
```
and moved it into an `impl`, there would be an error message:
"unexpected token `'a`"
Adding to the error message that a pattern is expected should help
users to find the actual problem with using a lifetime here.
|
|
|
|
|
|
|
|
The beginning of the work that needs to be done as part of #28835.
|
|
This reverts commit f4f95eb3a9f2c3c38679db84aabbb7cdb46d2641.
|
|
This reverts commit b3e1aca40f889a565bfa2607b82b80fe7cbcefea.
|
|
Makes rustbook code playpen links follow the style set in https://github.com/rust-lang/rust/pull/28963. This is basically cut and paste from the other one. The link looks better and still works so I assume it's good.
Fixes https://github.com/rust-lang/rust/issues/29308
r? @steveklabnik
|
|
|
|
As is, this attr would lead to the "///" prefix being in the output text.
|
|
I somehow missed a word behind the numbers while going through this section, don't know what the best approach would be though since "**available** addresses" sounds good to me, too".
|
|
Closes #21410.
Closes #24972.
|
|
Another kind of nominal types in Rust are trait objects, so the following is valid
```rust
trait A {
}
impl A {
}
```
|
|
And use `VariantData` instead of `P<VariantData>` in `Item_` and `Variant_`
Improvements suggested by @eddyb in https://github.com/rust-lang/rust/pull/28816#discussion_r42483587 and https://github.com/rust-lang/rust/pull/28816#discussion_r42483648
plugin-[breaking-change]
r? @eddyb
|
|
Added a single character to fix a typo in a doc comment.
|
|
We don't need the support libgcc SEH library, but we do need the C++ standard
library for running the compiler itself.
cc #29208
Closes #29294
|
|
|
|
Closes #21410.
Closes #24972.
|
|
instead of this panic:
```
thread '<main>' panicked at 'index out of bounds: the len is 1 but the
index is 1', src/libcollections/vec.rs:1110
```
It still panics, just like `-h` does, so it should be okay in this
regard.
|
|
Closes #22781.
Closes #23891.
Closes #24956.
Closes #25145.
Closes #25693.
Closes #26095.
Closes #26459.
Closes #27320.
Closes #27895.
|
|
new style
|
