| Age | Commit message (Collapse) | Author | Lines |
|
|
|
Backport rustdoc ICE fixes to beta
backport of #47959
|
|
|
|
[beta] Backports
Cherry-picked into beta:
- #47762
- #47794
- #47891
|
|
Backport 47738 to beta
Backport of #47738 to beta branch.
|
|
|
|
|
|
MIR's `Const::get_field()` attempts to retrieve the value for a given
field in a constant. In the case of a union constant it was falling
through to a generic `const_get_elt` based on the field index. As union
fields don't have an index this caused an ICE in `llvm_field_index`.
Fix by simply returning the current value when accessing any field in a
union. This works because all union fields start at byte offset 0.
The added test uses `const_fn` it ensure the field is extracted using
MIR's const evaluation. The crash is reproducible without it, however.
Fixes #47788
|
|
Fixes #47139
|
|
When spawning a linker rustc has historically been known to blow OS limits for
the command line being too large, notably on Windows. This is especially true of
incremental compilation where there can be dozens of object files per
compilation. The compiler currently has logic for detecting a failure to spawn
and instead passing arguments via a file instead, but this failure detection
only triggers if a process actually fails to spawn.
Unfortunately on Windows we've got something else to worry about which is
`cmd.exe`. The compiler may be running a linker through `cmd.exe` where
`cmd.exe` has a limit of 8192 on the command line vs 32k on `CreateProcess`.
Moreso rustc actually succeeds in spawning `cmd.exe` today, it's just that after
it's running `cmd.exe` fails to spawn its child, which rustc doesn't currently
detect.
Consequently this commit updates the logic for the spawning the linker on
Windows to instead have a heuristic to see if we need to pass arguments via a
file. This heuristic is an overly pessimistic and "inaccurate" calculation which
just calls `len` on a bunch of `OsString` instances (where `len` is not
precisely the length in u16 elements). This number, when exceeding the 6k
threshold, will force rustc to always pass arguments through a file.
This strategy should avoid us trying to parse the output on Windows of the
linker to see if it successfully spawned yet failed to actually sub-spawn the
linker. We may just be passing arguments through files a little more commonly
now...
The motivation for this commit was a recent bug in Gecko [1] when beta testing,
notably when incremental compilation was enabled it blew out the limit on
`cmd.exe`. This commit will also fix #46999 as well though as emscripten uses a
bat script as well (and we're blowing the limit there).
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1430886
Closes #46999
(cherry picked from commit 66366f9)
|
|
The match lowering code, when lowering matches against bytestrings,
works by coercing both the scrutinee and the pattern to `&[u8]` and
then comparing them using `<[u8] as Eq>::eq`.
If the scrutinee is already of type `&[u8]`, then unsizing it is both
unneccessary and a trait error caught by the new and updated MIR typeck,
so this PR changes lowering to avoid doing that (match lowering tried to
avoid that before, but that attempt was quite broken).
Fixes #46920.
|
|
|
|
Closes #47278
|
|
|
|
|
|
Add compiler docs testing to CI.
Fixes #47025.
I don't know if `x86_64-gnu` is the right builder for this, but there seems to be time left on [Travis](https://travis-ci.org/rust-lang/rust/jobs/307488864).
Remaining problems blocking this PR:
- [x] broken links caused by rustdoc issues:
- [x] `pub use self::Enum::...`: #46766 and #46767 (fixed by #47050, thanks @ollie27!)
- [x] `impl Deref for DerefToStdType`: #32129 (ignored in linkchecker)
- [x] `#[feature(decl_macro)]` and `use std::vec`: #47038 (ignored in linkchecker)
- [x] `rustc_data_structures::sync::{Lrc, RwLock}` aliases `std` types: #32130 (ignored in linkchecker)
- [x] markdown differences, in rust repository and in external crates, now failing the build with #46880 merged (all fixed)
- [x] multiple crate updates needed: `rand`, `log`, `parking_lot_core`, `flate2`
- [x] submodule updates needed to deduplicate dependencies: `rust-installer`, ~`cargo`~ (done by #47052)
- [x] #44953 test broken by `log` update (removed, this can be controversial)
- [x] Waiting `x86_64-gnu` build results ([done](https://travis-ci.org/rust-lang/rust/builds/323451069))
See individual commits for more details.
|
|
It tested #44953.
`log` macros in newer versions are no longer recursive, so these duplicated
error messages (about unstable feature uses) previously occurring at each
level of recursion are no longer possible, even with the fix by #45540.
Furthermore this test breaks when multiple versions of `log` are in the
sysroot (`log 0.3.9` depends on`log 0.4.1`)
|
|
Reword trying to operate in immutable fields
The previous message ("cannot assign/mutably borrow immutable field")
when trying to modify a field of an immutable binding gave the
(incorrect) impression that fields can be mutable independently of their
ADT's binding. Slightly reword the message to read "cannot
assign/mutably borrow field of immutable binding".
Re #35937.
|
|
Allow lifetimes in macros
This is a resurrection of PR #41927 which was a resurrection of #33135, which is intended to fix #34303.
In short, this allows macros_rules! to use :lifetime as a matcher to match 'lifetimes.
Still to do:
- [x] Feature gate
|
|
Add a tidy check for missing or too many trailing newlines.
I've noticed recently there are lots of review comments requesting to fix trailing newlines. If this is going to be an official style here, it's better to let the CI do this repetitive check.
|
|
The previous message ("cannot assign/mutably borrow immutable field")
when trying to modify a field of an immutable binding gave the
(incorrect) impression that fields can be mutable independently of their
ADT's binding. Slightly reword the message to read "cannot
assign/mutably borrow field of immutable binding".
|
|
It's unnecessary to print the linker options if there is no linker installed.
Currently, for libraries, the output is still printed, see #46998 for
discussion
|
|
zackmdavis:and_the_case_of_the_bloated_tuple_struct_indices, r=petrochenkov
in which leading zeroes on tuple-struct accesses are abjured
Resolves #47073. If accepted, a point in the compatibility section of the release notes is warranted.
|
|
Resolves #47073.
|
|
Add tests on fixed ICEs
Closes #29924. Closes #38857. Closes #39665. Closes #39872.
Closes #41210. Closes #41880. Closes #43483.
Note that compile-fail/E0599.rs is for #41210.
|
|
Closes #29924. Closes #38857. Closes #39665. Closes #39872.
Closes #39553. Closes #41210. Closes #41880. Closes #43483.
|
|
|
|
|
|
rustdoc: Don't try to generate links for modules in import paths
The modules may be private or may even be enums so it would generate dead links.
Fixes #29814
Fixes #46766
Fixes #46767
|
|
The modules may be private or may even be enums so it would generate dead links.
|
|
|
|
|
|
Started rebasing @sgrif's PR #33135 off of current master. (Well, actually merging it into a new branch based off current master.)
The following files still need to be fixed or at least reviewed:
- `src/libsyntax/ext/tt/macro_parser.rs`: calls `Parser::parse_lifetime`, which doesn't exist anymore
- `src/libsyntax/parse/parser.rs`: @sgrif added an error message to `Parser::parse_lifetime`. Code has since been refactored, so I just took it out for now.
- `src/libsyntax/ext/tt/transcribe.rs`: This code has been refactored bigtime. Not sure whether @sgrif's changes here are still necessary. Took it out for this commit.
|
|
Pass correct span when lowering grouped imports
Solves incorrect diagnostics for unused or deprecated imports. Closes #46576.
Deprecated imports had an existing test which asserted the incorrect span.
That test has been corrected as part of this commit.
|
|
Report an error when resolving non-ident macro path failed
Closes #41719.
Please feel free to bikeshed on the error message.
|
|
Do not expand a derive invocation when derive is not allowed
Closes #46655.
The first commit is what actually closes #46655. The second one is just a refactoring I have done while waiting on a test.
|
|
|
|
Do not panic on interpolated token inside quote macro
Closes #33469.
|
|
Add tests to fixed ICEs
Closes #27078. Closes #27985. Closes #39848. Closes #42164.
Closes #42479. Closes #45662. Closes #45965. Closes #46152.
|
|
|
|
Implements RFC 1937: `?` in `main`
This is the first part of the RFC 1937 that supports new
`Termination` trait in the rust `main` function.
Thanks @nikomatsakis, @arielb1 and all other people in the gitter channel for all your help!
The support for doctest and `#[test]` is still missing, bu as @nikomatsakis said, smaller pull requests are better :)
|
|
rustc_trans: support ZST indexing involving uninhabited types.
Fixes #46855 in a minimal way. I decided against supporting non-memory `Rvalue::Len` in this PR (see https://github.com/rust-lang/rust/issues/46855#issuecomment-352965807), as `PlaceContext::Inspect` is also used for `Rvalue::Discriminant`.
r? @arielb1
|
|
rustc: don't use union layouts for tagged union enums.
Fixes #46897, fixes #43517 (AFAICT from the testcases).
This PR doesn't add any testcases, we should try to at least get perf ones (cc @Mark-Simulacrum).
I couldn't find an example in those issues where the choice of LLVM array vs struct (with N identical fields) for padding filler types is still needed, *on top of* this change, to prevent excessive LLVM sinking.
r? @arielb1
|
|
Make the output of the column! macro 1 based
Fixes #46868.
I didn't add any regression tests as the change already had to change tests inside the codebase.
r? @dtolnay
|
|
Use def span for non-ascii ident feature gate error
|
|
This reverts commit 267800a7c0834dd8ca93a82a20cb0cdd9e7dc025.
|
|
[MIR Borrowck] Moveck inline asm statements
Closes #45695
New behavior:
* Input operands to `asm!` are moved, direct output operands are initialized.
* Direct, non-read-write outputs match the assignment changes in #46752 (Shallow writes, end borrows).
|
|
|
|
|
|
Solves incorrect diagnostics for unused or deprecated imports. Closes #46576.
Deprecated imports had an existing test which asserted the incorrect span.
That test has been corrected as part of this commit.
|