| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
This pulls in the rest of LLVM's `release_60` branch (the actual 6.0.0 release)
and also pulls in a cherry-pick to...
Closes #48226
|
|
|
|
The former seems much more stable, in case the cache becomes invalidated.
|
|
|
|
Same problem as OpenBSD, tracking bug #43575.
Backport from #48494
|
|
CC #42681
|
|
[beta] rustbuild: pass datadir to rust-installer
Backport from #48295
|
|
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
|
|
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
|
|
|
|
This re-introduces a `Config.libdir_relative` field, now derived from
`libdir` and made relative to `prefix` if necessary.
This fixes a regression from #46592 when `--libdir` is given an absolute
path. `Builder::sysroot_libdir` should always use a relative path so
its callers don't clobber system locations, and `librustc` also asserts
that `CFG_LIBDIR_RELATIVE` is really relative.
|
|
|
|
|
|
[beta] properly run doctests in standalone markdown files with pulldown
This is a beta-specific fix for https://github.com/rust-lang/rust/issues/48327, since a different fix landed in nightly (https://github.com/rust-lang/rust/pull/48274) that is infeasible to backport.
The nature of the issue was that when running doctests on standalone Markdown files, rustdoc names the tests based on the headings in the files. Therefore, with the following `a.md`:
``````markdown
# My Cool Library
This is my cool library!
## Examples
Here's some cool code samples!
```rust
assert_eq!(2+2, 4);
```
``````
Running this file with `rustdoc --test a.md` would show a test named `a.md - my_cool_library::examples (line 9)`. So far, this works just fine between Hoedown and Pulldown. But it gets murkier when you introduce markup into your headings. Consider the following `b.md`:
``````markdown
# My Cool Library
This is my cool library!
## `libcool`
```rust
assert_eq!(2+2, 4);
```
``````
The code surrounding the different renderers handles this differently. Pulldown handles just the first `Text` event after seeing the header, so it names the test `b.md - my_cool_library::libcool (line 9)`. Hoedown, on the other hand, takes all the test within the heading, which Hoedown renders before handing to library code. Therefore, it will name the test `b.md - my_cool_library::_code_libcool__code_ (line 9)`. (Somewhere between rustdoc and libtest, the `</>` characters are replaced with underscores.)
This causes a problem with another piece of code: The one that checks for whether Pulldown detected a code block that Hoedown didn't. The test collector groups the "old tests" listing by the full test name, but it *inserts* with the Hoedown name, and *searches* for the Pulldown name! This creates a situation where when `b.md` from above is run, it can't find a matching test from the ones Hoedown extracted, so it discards it and emits a warning.
On nightly, this has been fixed by... ditching Hoedown entirely. This also removed the code that tracked the different test listings, and made it run the test anyway. Since backporting the Hoedown removal is infeasible (i'm personally relying on the change to ride the trains to give the stabilization enough time to complete), this instead chooses to group the test by the filename, instead of the full test name as before. This means that the test extractor finds the test properly, and properly runs the test.
|
|
[beta] Backport "Fix rustdoc test ICE"
https://github.com/rust-lang/rust/pull/48382
|
|
[beta] backport cargo TLS warning for win7
https://github.com/rust-lang/cargo/pull/5069
r? @alexcrichton
|
|
https://github.com/rust-lang/cargo/pull/5069
|
|
[beta] temporarily disable rust-lang/rust#46833 due to rust-lang/rust#48251
see also https://github.com/rust-lang/rust/pull/48378
r? @Mark-Simulacrum
|
|
|
|
|
|
|
|
|
|
|
|
We'd previously assumed that these paths would be relative to the src
dir, and that for example our various CI scripts would, when calling
x.py, use `../x.py build ../src/tools/...` but this isn't the case --
they use `../x.py` without using the relevant source-relative path.
We eventually may want to make this (actually somewhat logical) change,
but this is not that time.
|
|
Primarily for CI purposes; this is intended to avoid cases where we
update rustbuild and unintentionally make CI stop running some builds to
the arguments being passed no longer applying for some reason.
|
|
|
|
|
|
Implement excluding a build-step via --exclude
First step to fixing https://github.com/rust-lang/rust/issues/47911. This doesn't change any CI configuration, but implements what I believe necessary to make that feasible in rustbuild.
In theory this should be sufficient to allow someone to open a PR against .travis.yml and appveyor.yml which splits the Windows 32-bit tests and maybe the OS X tests into multiple builders (depending on what our cost-concerns are) to reduce runtimes.
r? @alexcrichton
cc @kennytm
|
|
Update RLS
Should fix the RLS test breakage.
r? @alexcrichton
|
|
|
|
This reverts commit 64a8730e171367e4979cd9c25f0e0fdc2c157446.
|
|
Removed the `assume()` which we assumed is the cause of misoptimization in
issue #48116.
|
|
|
|
Some Steps are by-default run but don't have any paths associated with
them. We need to have at least one PathSet per each Step, though, so we
add an empty one on calls to `never()`.
|
|
1. When the invalid condition is hit, write out the relevant variables too
2. In compile-fail/parse-fail tests, check for ICE first, so the invalid
error patterns won't mask our ICE output.
|
|
Optimized error reporting for recursive requirements #47720
Fixes #47720
|
|
Add `-Zteach` documentation
Add extra inline documentation to E0019, E0016, E0013, E0396, E0017,
E0018, E0010, E0022, E0030, E0029, E0033, E0026 and E0027.
Follow up to #47652.
|
|
Compiletest: delete the compiled program once its test is done.
Reduces CI disk usage which prevents #48118 from succeeding.
|
|
This isn't a perfect heuristic, but since the amount of run-fail tests
is far lower than run-pass tests for now, it should be sufficient to
ensure that we don't run into CI limits. This makes it possible to run
the test binary manually (e.g., under gdb/lldb) if it failed to attempt
to find out why.
|
|
This should save a lot of space on musl test cases (whose standard library
are linked statically).
|
|
Implement `?` macro repetition
See rust-lang/rfcs#2298 (with disposition merge)
|
|
Previously, a Step would be able to tell on its own when it was invoked
"by-default" (that is, `./x.py test` was called instead of `./x.py test
some/path`). This commit replaces that functionality, invoking each Step
with each of the paths it has specified as "should be invoked by."
For example, if a step calls `path("src/tools/cargo")` and
`path("src/doc/cargo")` then it's make_run will be called twice, with
"src/tools/cargo" and "src/doc/cargo." This makes it so that default
handling logic is in builder, instead of spread across various Steps.
However, this meant that some Step specifications needed to be updated,
since for example `rustdoc` can be built by `./x.py build
src/librustdoc` or `./x.py build src/tools/rustdoc`. A `PathSet`
abstraction is added that handles this: now, each Step can not only list
`path(...)` but also `paths(&[a, b, ...])` which will make it so that we
don't invoke it with each of the individual paths, instead invoking it
with the first path in the list (though this shouldn't be depended on).
Future work likely consists of implementing a better/easier way for a
given Step to work with "any" crate in-tree, especially those that want
to run tests, build, or check crates in the std, test, or rustc crate
trees. Currently this is rather painful to do as most of the logic is
duplicated across should_run and make_run. It seems likely this can be
abstracted away into builder somehow.
|
|
Fix oversized loads on x86_64 SysV FFI calls
The x86_64 SysV ABI should use exact sizes for small structs passed in
registers, i.e. a struct that occupies 3 bytes should use an i24,
instead of the i32 it currently uses.
Refs #45543
|
|
Emit data::Impl in save-analysis
As discussed on [internals.rust-lang](https://internals.rust-lang.org/t/rustdoc2-rls-analysis-and-the-compiler-help-wanted/6592/5), this PR emits `rls-data::Impl` in the save-analysis.
A number of questions are outstanding:
- [x] A few `???` around row 356. We need to discuss what goes here, if anything.
- [ ] ~~Deriving `id` for impl using hashing. Is this going to clash with rustc defids?~~
- [ ] ~~Deriving `id` for impl using hashing. Is the conversion from 64 bit -> 32 bit problematic?~~
- [x] Need a new rls-data with an `id` field in `Impl` struct.
- [ ] ~~Need a new rls-data which `derive` `Hash` for `ImplKind` enum.~~
|
|
rustc_mir: insert a dummy access to places being matched on, when building MIR.
Fixes #47412 by adding a `_dummy = Discriminant(place)` before each `match place {...}`.
r? @nikomatsakis
|
|
|
|
|
|
|
