| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fixes #25794
|
|
r? @eddyb
Fixes #19476.
|
|
- Successful merges: #25128, #25651, #25668, #25726, #25760, #25792, #25806, #25807
- Failed merges:
|
|
Quick update to fix two manpage issues I noticed in #25689.
|
|
Closes #20184
|
|
Currently, there are two conditional blocks that exist to check for "clang or gcc"
On line 866:
```
if [ -z "$CFG_ENABLE_CLANG" -a -z "$CFG_GCC" ]
then
err "either clang or gcc is required"
fi
```
and on line 1019:
```
if [ -z "$CC" -a -z "$CFG_ENABLE_CLANG" -a -z "$CFG_GCC" ]
then
err "either clang or gcc is required"
fi
```
Given the order of the clauses, this results in the "either clang or gcc is required" error from the earlier block, (even) when CC is set.
The expected behaviour is to honour user-flags, in this case CC.
Aside from removing all hand-holdy compiler checks in favour of actual compiler *feature* checks, this change removes the redundant former block in favour of the latter block, which appears designed to allow the expected behaviour.
|
|
Fixes #25622.
|
|
Currently part of the description of the `into_inner` method of `UnsafeCell` seems backwards.
|
|
|
|
Fixes #24816
r? @alexcrichton
|
|
Fixes #25438
|
|
Fixes #25326
|
|
|
|
|
|
The changes scaled back in 4cc025d8 were a little too aggressive and broke a
bunch of cross compilations by not defining the `LINK_$(1)` variable for all
targets. This commit ensures that the variable is defined for all targets by
defaulting it to the normal compiler if it's not already defined (it's only
defined specially for MSVC).
Closes #25723
Closes #25802
|
|
Windows tests can often deadlock if a child thread continues after the main
thread and then panics, and a `println!` executed in a child thread after the
main thread has exited is at risk of panicking.
|
|
Fixes #24644.
|
|
The current codegen tests only compare IR line counts between similar
rust and C programs, the latter getting compiled with clang. That looked
like a good idea back then, but actually things like lifetime intrinsics
mean that less IR isn't always better, so the metric isn't really
helpful.
Instead, we can start doing tests that check specific aspects of the
generated IR, like attributes or metadata. To do that, we can use LLVM's
FileCheck tool which has a number of useful features for such tests.
To start off, I created some tests for a few things that were recently
added and/or broken.
|
|
The current codegen tests only compare IR line counts between similar
rust and C programs, the latter getting compiled with clang. That looked
like a good idea back then, but actually things like lifetime intrinsics
mean that less IR isn't always better, so the metric isn't really
helpful.
Instead, we can start doing tests that check specific aspects of the
generated IR, like attributes or metadata. To do that, we can use LLVM's
FileCheck tool which has a number of useful features for such tests.
To start off, I created some tests for a few things that were recently
added and/or broken.
|
|
Closes #25812.
|
|
|
|
|
|
|
|
|
|
Currently, for `use` declarations with multiple paths, only the `use` item itself is saved in the AST map, not the individual path nodes. This can lead to a problem when a span of a specific path node is needed.
For example, #24818 caused an ICE because of this, in `ImportResolver::check_for_conflicting_import()`.
Fixes #25763.
|
|
This is enough to make `make tidy` work if you're using python3
There's definitely more stuff to do, but PR'ing now to avoid bitrot
|
|
The second commit seems reasonable to me but I can remove if it's contentious. The first is purely cosmetic but has been irking me for ages.
|
|
Needed to support:
```rust
match X {
pattern if Y ...
}
for pattern in Y {}
```
IMO, this shouldn't require an RFC because it can't interfere with any future language changes (because `pattern if` and `pattern in` are already legal in rust) and can't cause any ambiguity.
|
|
rustc -C target-cpu=help is no longer supported. Recommend the
llc tool intead like 'rustc --help'.
|
|
Estimating August as the release date for 1.2.0.
|
|
- Adds explanations for E0055, E0089, E0192, E0261-E0263, E0318
- Improves explanations for E0250, E0368, E0372.
- Converts 15 diagnostics to have error codes (E0380-E0394). Adds an explanation for E0380.
- The E0087-E0090 messages currently look like "expected {} parameter(s) found {} parameter(s)". This changes them to either use "parameter" or "parameters", based on the number.
This is, in part, more progress towards #24407
|
|
Fixes #24816
|
|
Closes #20184
|
|
The output of individual tests can be captured now so it's safe to use
colorized output even when running tests in parallel. Closes #782.
|
|
rustdoc: Associated type fixes
The first commit fixes a bug with "dud" items in the search index from
misrepresented `type` items in trait impl blocks.
For a trait *implementation* there are typedefs which are the types for
that particular trait and implementor. Skip these in the search index.
There were lots of dud items in the search index due to this (search for
Item, Iterator's associated type).
Add a boolean to clean::TypedefItem so that it tracks whether the it is
a type alias on its own, or if it's a `type` item in a trait impl.
The second commit fixes a bug that made signatures and where bounds
using associated types (if they were not on `Self`) incorrect.
The third commit fixes so that where clauses in type alias definititons
are shown.
Fixes #22442
Fixes #24417
Fixes #25769
|
|
Also adds explanations for E0380 and E0381.
|
|
|
|
|
|
|
|
|
|
Fixes #24575
Fixes #25673
r? @alexcrichton
|
|
this asserts that source is valid utf8 on both python3 and python2
|
|
Changes:
- adds explanations for E0185, E0186, E0202, E0326
- fixes the explanation for E0053. The previous description was too narrow; there are other error cases.
- changes the error message for E0202 to be specific for associated types, since it seems inherent associated constants are implemented.
Part of #24407
|
|
The changes scaled back in 4cc025d8 were a little too aggressive and broke a
bunch of cross compilations by not defining the `LINK_$(1)` variable for all
targets. This commit ensures that the variable is defined for all targets by
defaulting it to the normal compiler if it's not already defined (it's only
defined specially for MSVC).
Closes #25723
|
|
Fixes #23037.
Fixes #25339.
|
|
Closes #25046 (by rejecting the code that causes the ICE) and #24946. I haven't been able to deal with the array size or recursion issues yet for associated consts, though my hope was that the change I made for range match patterns might help with array sizes, too.
This PR is pretty much orthogonal to #25065.
|
|
|
|
Fixes #24644.
|
|
|
|
This flag indicates that when files are being replaced or added to archives (the
`r` flag) that the new file should not be inserted if it is not newer than the
file that already exists in the archive. The compiler never actually has a use
case of *not* wanting to insert a file because it already exists, and this
causes rlibs to not be updated in some cases when the compiler was re-run too
quickly.
Closes #18913
|
