| Age | Commit message (Collapse) | Author | Lines |
|---|
|
don't make crazy suggestion for unreachable braced pub-use
The Higher Intermediate Representation doesn't have spans for visibility
keywords, so we were assuming that the first whitespace-delimited token
in the item span was the `pub` to be weakened. This doesn't work for
brace-grouped `use`s, which get lowered as if they were several
individual `use` statements, but with spans that only cover the braced
path-segments. Constructing a correct suggestion here presents some
challenges—until someone works those out, we can at least protect the
dignity of our compiler by not offering any suggestion at all for `use` items.
This resolves #50455 (but again, it would be desirable in the future to
make a correct suggestion instead of copping out like this).
r? @Manishearth
|
|
Introduce ConstValue and use it instead of miri's Value for constant values
r? @oli-obk
|
|
added missing implementation hint
Fixes [#50151](https://github.com/rust-lang/rust/issues/50151).
Actually, i don't know, should following code
`let x = |ref x: isize| { x += 1; };`
emit
`note: an implementation of std::ops::AddAssign might be missing for &isize`
or
`note: this is a reference to a type that + can be applied to; you need to dereference this variable once for this operation to work`
or both
|
|
Use the correct crt*.o files when linking musl targets.
This is supposed to support optionally using the system copy of musl
libc instead of the included one if supported. This currently only
affects the start files, which is enough to allow building rustc on musl
targets.
Most of the changes are analogous to crt-static.
Excluding the start files is something musl based distributions usually patch into their copy of rustc:
- https://github.com/alpinelinux/aports/blob/eb064c8/community/rust/musl-fix-linux_musl_base.patch
- https://github.com/voidlinux/void-packages/blob/77400fc/srcpkgs/rust/patches/link-musl-dynamically.patch
For third-party distributions that not yet carry those patches it would be nice if it was supported without the need to patch upstream sources.
## Reasons
### What breaks?
Some start files were missed when originally writing the logic to swap in musl start files (gcc comes with its own start files, which are suppressed by -nostdlib, but not manually included later on). This caused #36710, which also affects rustc with the internal llvm copy or any other system libraries that need crtbegin/crtend.
### How is it fixed?
The system linker already has all the logic to decide which start files to include, so we can just defer to it (except of course if it doesn't target musl).
### Why is it optional?
In #40113 it was first tried to remove the start files, which broke compiling musl-targeting static binaries with a glibc-targeting compiler. This is why it eventually landed without removing the start files. Being an option side-steps the issue.
### Why are the start files still installed?
This has the nice side-effect, that the produced rust-std-* binaries can still be used by on a glibc-targeting system with a rustc built against glibc.
## Does it work?
With the following build script (using [musl-cross-make](https://github.com/richfelker/musl-cross-make)): https://shadowice.org/~mixi/rust-musl/build.sh, I was able to cross-compile a musl-host musl-targeting rustc on a glibc-based system. The resulting binaries are at https://shadowice.org/~mixi/rust-musl/binaries/. This also requires #50103 and #50104 (which are also applied to the branch the build script uses).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The Higher Intermediate Representation doesn't have spans for visibility
keywords, so we were assuming that the first whitespace-delimited token
in the item span was the `pub` to be weakened. This doesn't work for
brace-grouped `use`s, which get lowered as if they were several
individual `use` statements, but with spans that only cover the braced
path-segments. Constructing a correct suggestion here presents some
challenges—until someone works those out, we can at least protect the
dignity of our compiler marking the suggestion for `use` items as
potentially incorrect.
This resolves #50455 (but again, it would be desirable in the future to
make a correct suggestion instead of copping out like this).
|
|
Improve single-use and zero-use lifetime lints
The code now correctly identifies *when* to lint -- or more correctly, anyhow -- but it doesn't yet offer suggestions for how to fix.
(I just remembered when writing this I had meant to go back over some of these cases around e.g. impl Trait and double check that everything is right...)
cc #44752
r? @cramertj
|
|
Rollup of 18 pull requests
Successful merges:
- #49423 (Extend tests for RFC1598 (GAT))
- #50010 (Give SliceIndex impls a test suite of girth befitting the implementation (and fix a UTF8 boundary check))
- #50447 (Fix update-references for tests within subdirectories.)
- #50514 (Pull in a wasm fix from LLVM upstream)
- #50524 (Make DepGraph::previous_work_products immutable)
- #50532 (Don't use Lock for heavily accessed CrateMetadata::cnum_map.)
- #50538 ( Make CrateNum allocation more thread-safe. )
- #50564 (Inline `Span` methods.)
- #50565 (Use SmallVec for DepNodeIndex within dep_graph.)
- #50569 (Allow for specifying a linker plugin for cross-language LTO)
- #50572 (Clarify in the docs that `mul_add` is not always faster.)
- #50574 (add fn `into_inner(self) -> (Idx, Idx)` to RangeInclusive (#49022))
- #50575 (std: Avoid `ptr::copy` if unnecessary in `vec::Drain`)
- #50588 (Move "See also" disambiguation links for primitive types to top)
- #50590 (Fix tuple struct field spans)
- #50591 (Restore RawVec::reserve* documentation)
- #50598 (Remove unnecessary mutable borrow and resizing in DepGraph::serialize)
- #50606 (Retry when downloading the Docker cache.)
Failed merges:
- #50161 (added missing implementation hint)
- #50558 (Remove all reference to DepGraph::work_products)
|
|
Fix tuple struct field spans
Fix #50578. Will have a merge conflict with #50536.
|
|
Allow for specifying a linker plugin for cross-language LTO
This PR makes the `-Zcross-lang-lto` flag optionally take the path to the `LLVMgold.so` linker plugin. If this path is specified, `rustc` will invoke the linker with the correct arguments (i.e. `-plugin` and various `-plugin-opt`s).
This can be used to ergonomically enable cross-language LTO for Rust programs with C/C++ dependencies:
```
clang -O2 test.c -otest.o -c -flto=thin
llvm-ar -rv libxxx.a test.o
rustc -L. main.rs -Zcross-lang-lto=/usr/lib64/LLVMgold.so -O -Clink-arg=-fuse-ld=gold
```
- Note that in theory this should work with Gold, LLD, and newer versions of binutils' LD but on my current system I could only get it to work with Gold.
- Also note that this will work best if the Clang version and Rust's LLVM version are close enough. Clang 6.0 works well with the current nightly.
r? @alexcrichton
|
|
Fix update-references for tests within subdirectories.
Fixes #50438.
I'll make this more robust later for #49815.
|
|
Extend tests for RFC1598 (GAT)
More GAT tests, namely some usage for `Iterable` and `StreamingIterator`, shadowing (lifetimes and type params), `Collection<T>` and `CollectionFamily` from [the series](http://smallcultfollowing.com/babysteps/blog/2016/11/03/associated-type-constructors-part-2-family-traits/) with default associated types. Tracking issue: #44265
r? @nikomatsakis
Wrong GAT argument numbers / kinds and default values are next.
|
|
Remove usages of Term::as_str and mark it for removal
Returning references to rustc internal data structures is a bad idea since their lifetimes are unrelated to the lifetimes of proc_macro values.
See https://github.com/rust-lang/rust/pull/46972 and the `Taming thread-local storage` section of https://internals.rust-lang.org/t/parallelizing-rustc-using-rayon/6606
r? @alexcrichton
|
|
|
|
Fix rustdoc pathes search
Fixes #50086.
Depends on #50302.
r? @QuietMisdreavus
|
|
|
|
|
|
Added regression function match value test
closes #44333
|
|
Make `String::new()` const
Following the steps of https://github.com/rust-lang/rust/pull/50233 , make `String::new()` a `const fn`.
|
|
Fixes #50438.
I'll make this more robust later for #49815.
|
|
Fix thinning pointers to extern types in miri
r? @kennytm as an alternative to disabling the miri build
fixes #50495
|
|
|
|
lint: deny incoherent_fundamental_impls by default
Warn the ecosystem of the pending intent-to-disallow in #49799.
There are 4 ICEs on my machine, look unrelated (having happened before in https://github.com/rust-lang/rust/issues/49146#issuecomment-384473523)
```rust
thread 'main' panicked at 'assertion failed: position <= slice.len()', libserialize/leb128.rs:97:1
```
```
[run-pass] run-pass/allocator/xcrate-use2.rs
[run-pass] run-pass/issue-12133-3.rs
[run-pass] run-pass/issue-32518.rs
[run-pass] run-pass/trait-default-method-xc-2.rs
```
r? @nikomatsakis
|
|
idiom lints for removing `extern crate`
Based off of https://github.com/rust-lang/rust/pull/49789
This contains two lints:
- One that suggests replacing pub extern crates with pub use, and removing non-pub extern crates entirely
- One that suggests rewriting `use modulename::...::cratename::foo` as `cratename::foo`
The latter is a bit tricky to emit suggestions for; for one this involves splicing spans (never a good idea), and it also won't be able to correctly
handle `use module::{cratename, foo}` and use-trees. I'm not sure how to proceed here. Currently it doesn't suggest anything at all.
Perhaps we can go the other way and suggest removal of all extern crates _except_ those used through modules (stash node ids somewhere) and suggest replacing those with `<visibility> use`?
r? @nikomatsakis
fixes https://github.com/rust-lang/rust/issues/48719
|
|
Prevent infinite recursion of modules
Fixes #50196.
r? @QuietMisdreavus
|
|
|
|
Various edition preview fixes
Implement a bunch of things discussed in the meeting.
|
|
|
|
Add some groundwork for cross-language LTO.
Implements part of #49879:
- Adds a `-Z cross-lang-lto` flag to rustc
- Makes sure that bitcode is embedded in object files if the flag is set.
This should already allow for using cross language LTO for staticlibs (where one has to invoke the linker manually anyway). However, `rustc` will not try to enable LTO for its own linker invocations yet.
r? @alexcrichton
|
|
|
|
Also, a comment is edited to reflect that spaces around the equals-sign in
attributes is the standard (q.v. rust-lang-nursery/fmt-rfcs@bea80532e7).
|
|
|
|
Misc tweaks
This:
- ~~Add explicit dependencies on `getops`~~
- Fixes the libtest-json test when `RUST_BACKTRACE=1` is set
- ~~Sets `opt-level` to `3`~~
- Removes the use of `staged_api` from `rustc_plugin`
- ~~Enables the Windows Error Reporting dialog when running rustc during bootstrapping~~
- Disables Windows Error Reporting dialog when running compiletest tests
- Enables backtraces when running rustc during bootstrapping
- ~~Removes the `librustc` dependency on `libtest`~~
- Triggers JIT debugging on Windows if rustc panics during bootstrapping
r? @alexcrichton
|
|
|
|
|
|
|
|
|
|
rustdoc: Resolve nested `impl Trait`s
Fixes #50358.
Populates `cx.impl_trait_bounds` incrementally while `clean`ing generic params, so that a synthetic type-parameter can refer to previous ones.
cc #50366
|
|
|
|
This commit adds a dedicated mode to compiletest for running rustfix tests,
adding a new `src/test/rustfix` directory which will execute all tests as a
"rustfix" test, namely requiring that a `*.fixed` is next to the main file which
is the result of the rustfix project's application of fixes.
The `rustfix` crate is pulled in to actually perform the fixing, and the rustfix
compiletest mode will assert a few properties about the fixing:
* The expected fixed output must be the same as rustc's output suggestions
applied to the original code.
* The fixed code must compile successfully
* The fixed code must have no further diagnostics emitted about it
|
|
This is the first small step towards testing auto-fixable compiler
suggestions using compiletest. Currently, it only checks if next to a
UI test there also happens to a `*.rs.fixed` file, and then uses rustfix
(added as external crate) on the original file, and asserts that it
produces the fixed version.
To show that this works, I've included one such test. I picked this test
case at random (and because it was simple) -- It is not relevant to the
2018 edition. Indeed, in the near future, we want to be able to restrict
rustfix to edition-lints, so this test cast might go away soon.
In case you still think this is somewhat feature-complete, here's a
quick list of things currently missing that I want to add before telling
people they can use this:
- [ ] Make this an actual compiletest mode, with `test [fix] …` output
and everything
- [ ] Assert that fixed files still compile
- [ ] Assert that fixed files produce no (or a known set of) diagnostics
output
- [ ] Update `update-references.sh` to support rustfix
- [ ] Use a published version of rustfix (i.e.: publish a new version
rustfix that exposes a useful API for this)
|
|
|
|
|
|
pnkfelix:issue-27282-immut-borrow-all-pat-ids-in-guards, r=nikomatsakis
Immutably and implicitly borrow all pattern ids for their guards (NLL only)
This is an important piece of rust-lang/rust#27282.
It applies only to NLL mode. It is a change to MIR codegen that is currently toggled on only when NLL is turned on. It thus affect MIR-borrowck but not the earlier static analyses (such as the type checker).
This change makes it so that any pattern bindings of type T for a match arm will map to a `&T` within the context of the guard expression for that arm, but will continue to map to a `T` in the context of the arm body.
To avoid surfacing this type distinction in the user source code (which would be a severe change to the language and would also require far more revision to the compiler internals), any occurrence of such an identifier in the guard expression will automatically get a deref op applied to it.
So an input like:
```rust
let place = (1, Foo::new());
match place {
(1, foo) if inspect(foo) => feed(foo),
...
}
```
will be treated as if it were really something like:
```rust
let place = (1, Foo::new());
match place {
(1, Foo { .. }) if { let tmp1 = &place.1; inspect(*tmp1) }
=> { let tmp2 = place.1; feed(tmp2) },
...
}
```
And an input like:
```rust
let place = (2, Foo::new());
match place {
(2, ref mut foo) if inspect(foo) => feed(foo),
...
}
```
will be treated as if it were really something like:
```rust
let place = (2, Foo::new());
match place {
(2, Foo { .. }) if { let tmp1 = & &mut place.1; inspect(*tmp1) }
=> { let tmp2 = &mut place.1; feed(tmp2) },
...
}
```
In short, any pattern binding will always look like *some* kind of `&T` within the guard at least in terms of how the MIR-borrowck views it, and this will ensure that guard expressions cannot mutate their the match inputs via such bindings. (It also ensures that guard expressions can at most *copy* values from such bindings; non-Copy things cannot be moved via these pattern bindings in guard expressions, since one cannot move out of a `&T`.)
|
|
Remove the deprecated std::net::{lookup_host,LookupHost}
These are unstable, and were deprecated by #47510, since Rust 1.25. The
internal `sys` implementations are still kept to support the call in the
common `resolve_socket_addr`.
|
