| Age | Commit message (Collapse) | Author | Lines |
|
|
|
closes #31804
|
|
parser recovery (so that expected errors match up)
I'm opting into parser recovery in all these cases out of expediency,
not because the error messages you get with recovery enabled are
actually all that usable in all cases listed.
|
|
This works by adding a boolean flag, `continue_after_error`, to
`syntax::errors::Handler` that can be imperatively set to `true` or
`false` via a new `fn set_continue_after_error`.
The flag starts off true (since we generally try to recover from
compiler errors, and `Handler` is shared across all phases).
Then, during the `phase_1_parse_input`, we consult the setting of the
`-Z continue-parse-after-error` debug flag to determine whether we
should leave the flag set to `true` or should change it to `false`.
----
(We might consider adding a debugflag to do such aborts in other
places where we are currently attempting recovery, such as resolve,
but I think the parser is the really important case to handle in the
face of #31994 and the parser bugs of varying degrees that were
injected by parse error recovery.)
|
|
backport of 221d0fbad0b201ef9264d3c9a30cd8c143ed51b2 to beta
with hand-resolution of conflicts and reverting to `try!` syntax.
|
|
|
|
The addition of these methods in #31335 required adding impls of the trait for
the `String` and `Vec<T>` types. This unfortunately caused a regression (#32074)
in type inference for using these methods which the libs team has decided to not
push forward with. These methods were stabilized in #32020 which was intended to
get backported to beta, but the backport hasn't happened just yet. This commit
reverts both the addition and stabilization of these methods.
One proposed method of handling this, in #32076, was to move the methods to an
extra trait to avoid conflicts with type inference. After some discussion,
however, the libs team concluded that we probably want to reevaluate what we're
doing here, so discussion will continue on the tracking issue, #27809.
Conflicts:
src/libstd/ascii.rs
|
|
|
|
reported during the lifetime of this inferencer. Fixes #30580.
|
|
the assert was invalidated by PR #31020
Fixes #31561
|
|
Fixes #32004
|
|
|
|
Fixes #30891
|
|
|
|
Fix #31910.
|
|
The default implementations (with `where Self: Sized`) are so that methods that take `self` by value can exist in a trait that’s implemented for dynamically-sized types (`str` and `[u8]`).
CC https://github.com/rust-lang/rust/issues/27809#issuecomment-177564950
CC @alexcrichton
|
|
This commit implements documentation generation of the nomicon, the book, the
style guide, and the standalone docs. New steps were added for each one as well
as appropriate makefile targets for each one as well.
|
|
These commits add support to the rustbuild build system to compile non-build-system compilers. For example this will allow creating an ARM compiler on a x86 system. The high level way this works is:
* The only compiler ever run is the build target compiler. No other compiler is assumed to be runnable.
* As a result, all output artifacts come from the build compiler.
* The libs for the stageN cross-compiled compiler will be linked into place after the build target builds them.
This will break the assumption that a compiler never links to anything it didn't itself produce, but it retains the assumption that a compiler only ever links to anything built in the same stage. I believe this means that the stage1 cross-compiled compilers will still be usable.
I tested this by creating an `arm-unknown-linux-gnueabihf` compiler. So far the linking ended up all working OK (including LLVM being cross compiled), but I haven't been able to run it yet (in QEMU for a raspberry pi). I think that's because my system linker is messed up or something like that (some newer option is assumed when it's not actually there).
Overall, though, this means that rustbuild can compile an arm-unknown-linux-gnueabihf compiler. Ideally we could even start shipping nightlies based on this at some point!
|
|
This applies the same fix as added in 595d5b2f which is to just compile all
valgrind tests statically instead of dynamically. It looks like this is a
resurgence of either #30383 or #31328 in some weird fashion.
I'm not actually sure what's going on with the bots, and it's unclear whether
this is a valgrind bug or a libstd bug, but for now let's just get things
landing again.
Closes #30383
|
|
This commit is the result of the FCPs ending for the 1.8 release cycle for both
the libs and the lang suteams. The full list of changes are:
Stabilized
* `braced_empty_structs`
* `augmented_assignments`
* `str::encode_utf16` - renamed from `utf16_units`
* `str::EncodeUtf16` - renamed from `Utf16Units`
* `Ref::map`
* `RefMut::map`
* `ptr::drop_in_place`
* `time::Instant`
* `time::SystemTime`
* `{Instant,SystemTime}::now`
* `{Instant,SystemTime}::duration_since` - renamed from `duration_from_earlier`
* `{Instant,SystemTime}::elapsed`
* Various `Add`/`Sub` impls for `Time` and `SystemTime`
* `SystemTimeError`
* `SystemTimeError::duration`
* Various impls for `SystemTimeError`
* `UNIX_EPOCH`
* `ops::{Add,Sub,Mul,Div,Rem,BitAnd,BitOr,BitXor,Shl,Shr}Assign`
Deprecated
* Scoped TLS (the `scoped_thread_local!` macro)
* `Ref::filter_map`
* `RefMut::filter_map`
* `RwLockReadGuard::map`
* `RwLockWriteGuard::map`
* `Condvar::wait_timeout_with`
Closes #27714
Closes #27715
Closes #27746
Closes #27748
Closes #27908
Closes #29866
|
|
Constant evaluator can be called while tcx is in construction.
|
|
|
|
See https://doc.rust-lang.org/book/unsafe.html#what-does-safe-mean for the book version of these points which already contain the T.
|
|
|
|
|
|
|
|
Also, `path` seems better than `p`
|
|
* Fixes a warning with libc
* Brings in some new flag updates for various platforms through gcc-rs
* Otherwise routine updates here/there
|
|
Also fix a bug where we didn't clean out previous nightlies
|
|
This allows bootstrapping new platforms immediately in stage0
|
|
These should all no longer be necessary as they've been folded into the
compiler.
|
|
When cross compiling for a new host, we can't actually run the host compiler to
generate its own libs. In theory, however, all stage2 compilers (for any host)
will produce the same libraries, so we just require the build compiler to
produce the necessary host libraries and then we link those into place.
|
|
|
|
This switches the defaults to ensure that everything is built with the build
compiler rather than the host compiler itself (which we're not guaranteed to be
able to run)
|
|
Right now it's implicitly done as part of building the compiler, but this was
intended to be a standalone step to ensure we tracked what built what.
|
|
Fixes `--step librustc`
|
|
Currently all multi-host builds assume the the build platform can run the
`llvm-config` binary generated for each host platform we're creating a compiler
for. Unfortunately this assumption isn't always true when cross compiling, so we
need to handle this case.
This commit alters the build script of `rustc_llvm` to understand when it's
running an `llvm-config` which is different than the platform we're targeting for.
|
|
Needs a different target to get built and also we apparently need to appease the
C++ compiler somehow.
|
|
|
|
These flags aren't applicable to build scripts, and may actuall wreak havoc.
|
|
This commit fixes a longstanding issue with the makefiles where all host
platforms bootstrap themselves. This commit alters the build logic for the
bootstrap to instead only bootstrap the build triple, and all other compilers
are compiled from that one compiler.
The benefit of this change is that we can cross-compile compilers which cannot
run on the build platform. For example our builders could start creating
`arm-unknown-linux-gnueabihf` compilers.
This reduces the amount of bootstrapping we do, reducing the amount of test
coverage, but overall it should largely just end in faster build times for
multi-host compiles as well as enabling a feature which can't be done today.
cc #5258
|
|
Also, `path` seems better than `p`
|
|
fixes #31899
r? @alexcrichton
|
|
Make for loop desugaring for iterators more precise
The UFCS call IntoIterator::into_iter() is used by the for loop.
|
|
Refinement of paragraph referenced by [this issue](https://github.com/rust-lang/rust/issues/31927).
The paragraph in question had been adjusted already, but I've made some further clarifications which should help with readability and not leave the reader any `dangling pointers`.
|
|
Fixes https://github.com/rust-lang/rust/issues/31913
|
|
The UFCS call IntoIterator::into_iter() is used by the for loop.
|
|
See http://www.ietf.org/rfc/rfc2119.txt
|
|
|
|
|