This commit fixes a hard error where the `#![feature(rust_2018_preview)]`
feature was forbidden to be mentioned when the `--edition 2018` flag was passed.
This instead silently accepts that feature gate despite it not being necessary.
It's intended that this will help ease the transition into the 2018 edition as
users will, for the time being, start off with the `rust_2018_preview` feature
and no longer immediately need to remove it.
Closes#50662
Update canonicalize docs
I was recently working with file-paths in Rust, and I felt let down by the `std::fs::canonicalize` docs, so I figured I should submit a PR with some suggestions.
I was looking for a method to turn a relative path into an absolute path. The `canonicalize` docs didn't mention the words "relative" or "absolute", but they did mention resolving symlinks (which is a kind of canonicalisation and does not imply converting to absolute), so I assumed that's all it did. To remedy this, I've added the word "absolute" to the description of both `std::fs::canonicalize` and `std::path::Path::canonicalize`.
After calling `canonicalize` on Windows, I ran into a bunch of other problems I would not have expected from the function's behaviour on Linux. Specifically, if you call `canonicalize` on a path:
- it's allowed to be much longer than it otherwise would
- `.join("a/slash/delimited/path")` gives you a broken path that Windows can't use, where the same operation would have worked perfectly without `canonicalize` (if the path were short enough)
- the resulting path may confuse other Windows programs if you pass it to them on the command-line, or write it to a config file that they read, etc.
...so I tried to summarize those behaviours too.
If I understand correctly, those behaviours are a side-effect of calling `GetFinalPathNameByHandle`, and the documentation says `canonicalize` might not call that function in future, so maybe those side-effects shouldn't be part of the function's documentation. However, I bet there's a lot of applications deliberately calling `canonicalize` just for the path-length-extension alone, so that particular side-effect is de-facto part of the `canonicalize` interface.
Remove all reference to DepGraph::work_products
This is an attempt at fixing #50500. It will remove the `work_products` key from `DepGraphData` completely, in favour of just passing the relevant data around. I went in a little blindly; everything appears to work just fine but I'd appreciate any additional advice people.
I didn't want to remove too much of what was already there, so I kept the structure pretty much the same (aside from some naming tweaks) - if anyone has suggestions on how to streamline it a little better, happy to follow up.
r? @michaelwoerister
The LLVM PassManager has a PrepareForThinLTO flag, which is intended
when compilation occurs in conjunction with linking by ThinLTO. The
flag has two effects:
* The NameAnonGlobal pass is run after all other passes, which
ensures that all globals have a name.
* In optimized builds, a number of late passes (mainly related to
vectorization and unrolling) are disabled, on the rationale that
these a) will increase codesize of the intermediate artifacts
and b) will be run by ThinLTO again anyway.
This patch enables the use of PrepareForThinLTO if Thin or ThinLocal
linking is used.
The background for this change is the CI failure in #49479, which
we assume to be caused by the NameAnonGlobal pass not being run.
As this changes which passes LLVM runs, this might have performance
(or other) impact, so we want to land this separately.
Don't allocate when creating an empty BTree
Following the discussion in #50266, this adds a static instance of `LeafNode` that empty BTrees point to, and then replaces it on `insert`, `append`, and `entry`. This avoids allocating for empty maps.
Fixes#50266
r? @Gankro
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
If check_expr_struct_fields fails, do not continue to record update.
If we continue to record update, the struct may cause us to ICE later
on indexing a field that may or may not exist.
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
This commit updates one of the edition lints to only suggest deleting `extern
crate` if it actually works. Otherwise this can yield some confusing behavior
with rustfix specifically where if you accidentally deny the `rust_2018_idioms`
lint in the 2015 edition it's suggesting features that don't work!
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).
Currently the lint for removing `extern crate` suggests removing `extern crate`
most of the time, but the rest of the time it suggest replacing it with `use
crate_name`. Unfortunately though when spliced into the original code you're
replacing
extern crate foo;
with
use foo
which is syntactically invalid! This commit ensure that the trailing semicolon
is included in rustc's suggestion to ensure that the code continues to compile
afterwards.
This commit fixes a hard error where the `#![feature(rust_2018_preview)]`
feature was forbidden to be mentioned when the `--edition 2018` flag was passed.
This instead silently accepts that feature gate despite it not being necessary.
It's intended that this will help ease the transition into the 2018 edition as
users will, for the time being, start off with the `rust_2018_preview` feature
and no longer immediately need to remove it.
Closes#50662
Rename the 2018 edition lint names
* `rust_2018_breakage` -> `rust_2018_compatibility` - the lint for ensuring
that your code, in the 2015 edition, is compatible with the 2018 edition's
semantics. This is required to pass *before* you enable the 2018 edition.
* `rust_2018_migration` -> `rust_2018_idioms` - the lint for writing idiomatic
code after you've already enabled the 2018 edition
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
