There are some structures that are called "globals", but are they global
to a compilation session, and not truly global. I have always found this
highly confusing, so this commit renames them as "session globals" and
adds a comment explaining things.
Also, the commit fixes an unnecessary nesting of `set()` calls
`src/librustc_errors/json/tests.rs`
When the dockerfiles were moved into the host-x86_64 directory, paths
for COPY commands were updated with the new host-x86_64/ prefix. This
suggested that the intended context was src/ci/docker. However, the context
for disabled docker images was src/ci/docker/host-x86_64. This broke the new
paths and prevented src/ci/docker/scripts from being included in the
context at all.
This commit corrects this context allowing docker to find the files it
needs for COPY commands.
Suggested by @bjorn3
Every RUN command creates a new overlay on top of the image as of before
the RUN command. Using fewer RUN commands prevents intermediate overlays
(which in this case would have contained the entire Linux source tree).
Fix x.py test for librustc crates.
#73352 introduced a bug where `x.py test src/librustc_ast` would fail to actually run the tests. The issue is that `krate` and `all_krates` were changed to return relative paths. This caused the code to do a test of "relative_path ends with absolute path" which is always false. The solution is to swap that around.
The change to `Crate` isn't necessary, it just simplifies the code and makes it uniform with `CrateLibrustc`.
There don't seem to be any other compiletests that are 1) building a standalone "no_core" create and then 2) trying to link against it. There seems to be a platform-specific limitation in doing so:
```
2020-07-08T16:07:42.9419409Z = note: Creating library D:\a\rust\rust\build\i686-pc-windows-msvc\test\rustdoc\intra-link-prim-methods-external-core\auxiliary\my_core.dll.lib and object D:\a\rust\rust\build\i686-pc-windows-msvc\test\rustdoc\intra-link-prim-methods-external-core\auxiliary\my_core.dll.exp
2020-07-08T16:07:42.9419810Z LINK : error LNK2001: unresolved external symbol __DllMainCRTStartup@12
2020-07-08T16:07:42.9420032Z D:\a\rust\rust\build\i686-pc-windows-msvc\test\rustdoc\intra-link-prim-methods-external-core\auxiliary\my_core.dll : fatal error LNK1120: 1 unresolved externals
```
Possibly this could be resolved by adding a `__DllMainCRTStartup` or `__DllMainCRTStartup@12` symbol in an architecture- and platform-specific way.
Other terms are more inclusive and precise.
Clippy still has a lint named "blacklisted-name", but renaming it would
be a breaking change, so is left for future work.
The target configuration option "abi-blacklist" has been depreciated and
renamed to "unsupported-abis". The old name continues to work.
Fix occasional bootstrap panic in docs.
I am occasionally running into this panic when running `x.py`:
> thread 'main' panicked at 'source "/Users/eric/Proj/rust/rust/build/x86_64-apple-darwin/md-doc/unstable-book" failed to get metadata: No such file or directory (os error 2)', src/build_helper/lib.rs:173:19
I have not been able to figure out the exact sequence of commands that leads to this error (I tried for quite a while to reproduce it). I think it may involve updating my tree, but I am uncertain. An artificial way to trigger it is to build the documentation, and then delete the `md-doc` directory manually.
The cause is that bootstrap does a "dry run" before every command, and in this case `up_to_date` panics because the destination exists (`build/x86_64-apple-darwin/doc/unstable-book/index.html `) but the source does not (`build/x86_64-apple-darwin/md-doc/unstable-book`).
I am uncertain if it is important that the last line `builder.run(…)` needs to be called during the dry run. This patch seems to fix the issue, though.
Rename the existing read_at/write_at to read_vectored_at/write_vectored_at,
for consistency with libstd's read_vectored/write_vectored. And,
introduce new read_at/write_at functions which take a single buffer,
similar to all other targets which provide these functions, so this will
make it easier for applications to share code between WASI and other
targets.
Note that WASI's FileExt is currently unstable.
This pulls in a fix for the install script on some tr(1) implementations,
as well as an update to use `anyhow` instead of `failure` for error
handling.
Rollup of 14 pull requests
Successful merges:
- #70563 ([rustdoc] Page hash handling)
- #73856 (Edit librustc_lexer top-level docs)
- #73870 (typeck: adding type information to projection)
- #73953 (Audit hidden/short code suggestions)
- #73962 (libstd/net/tcp.rs: #![deny(unsafe_op_in_unsafe_fn)])
- #73969 (mir: mark mir construction temporaries as internal)
- #73974 (Move A|Rc::as_ptr from feature(weak_into_raw) to feature(rc_as_ptr))
- #74067 (rustdoc: Restore underline text decoration on hover for FQN in header)
- #74074 (Fix the return type of Windows' `OpenOptionsExt::security_qos_flags`.)
- #74078 (Always resolve type@primitive as a primitive, not a module)
- #74089 (Add rust-analyzer to the build manifest)
- #74090 (Remove unused RUSTC_DEBUG_ASSERTIONS)
- #74102 (Fix const prop ICE)
- #74112 (Expand abbreviation in core::ffi description)
Failed merges:
r? @ghost
Remove unused RUSTC_DEBUG_ASSERTIONS
Since #73374 the rustc wrapper no longer configures debug assertions
based on RUSTC_DEBUG_ASSERTIONS environment variable.
r? @RalfJung
Add rust-analyzer to the build manifest
Does not die locally, produces `rust-analyzer-0.1.0-dev-x86_64-unknown-linux-gnu.tar.gz.sha256` and add something about rust-analyzer to some `.toml` file. Seems like a success?
Always resolve type@primitive as a primitive, not a module
Previously, if there were a module in scope with the same name as the
primitive, that would take precedence. Coupled with
https://github.com/rust-lang/rust/issues/58699, this made it impossible
to link to the primitive when that module was in scope.
This approach could be extended so that `struct@foo` would no longer resolve
to any type, etc. However, it could not be used for glob imports:
```rust
pub mod foo {
pub struct Bar;
}
pub enum Bar {}
use foo::*;
// This is expected to link to `inner::Bar`, but instead it will link to the enum.
/// Link to [struct@Bar]
pub struct MyDocs;
```
The reason for this is that this change does not affect the resolution
algorithm of rustc_resolve at all. The only reason we could special-case
primitives is because we have a list of all possible primitives ahead of time.
Closes https://github.com/rust-lang/rust/issues/74063
r? @Manishearth
Fix the return type of Windows' `OpenOptionsExt::security_qos_flags`.
This adjusts the return type of Windows' `OpenOptionsExt::security_qos_flags`
to be consistent with the other functions in the trait.
rustdoc: Restore underline text decoration on hover for FQN in header
This causes the components of FQN's (e.g. `std`, `net`, and `Ipv4Addr` of the FQN `std::net::Ipv4Addr`) to behave similarly to other links in the contents of rustdoc-styled pages. When the user hovers over them, more clearly indicating that they can be used for navigation.
I (and I hope others at least in part) have found the prior design to be somewhat confusing, as it is not clear (upon hovering) that the various parts of the FQN are actually links that the user can navigate to.
<details><summary>📸 Before, mouse hovered over "net" in the FQN</summary>
<img alt="A rustdoc page with the mouse hovered over the fully-qualified name in the page header, producing no visual change" src="https://user-images.githubusercontent.com/1566689/86538363-4c827000-bebb-11ea-8291-5ea6b85d7e19.png" />
</details>
<details><summary>📸 After, mouse hovered over "net" in the FQN</summary>
<img alt="A rustdoc page with the mouse hovered over the fully-qualified name in the page header, now with an underline showing up under the word hovered over by the mouse" src="https://user-images.githubusercontent.com/1566689/86538471-d3374d00-bebb-11ea-9bb3-7aa2d7a4800b.png" />
</details>
Move A|Rc::as_ptr from feature(weak_into_raw) to feature(rc_as_ptr)
These were stabilized alongside the Weak versions, but having `feature = "weak_.."` on a fn definition for the non-weak pointers is potentially very misleading, especially in a review context where the impl header may not be immediately visible.
r? @RalfJung
@bors rollup=always
mir: mark mir construction temporaries as internal
Fixes#73914.
This PR marks temporaries from MIR construction as internal such that they are skipped in `sanitize_witness` (where each MIR local is checked to have been contained within the generator interior computed during typeck). This resolves an ICE whereby the construction of checked addition introduced a `(u64, bool)` temporary which was not in the HIR and thus not in the generator interior.
r? @matthewjasper
Audit hidden/short code suggestions
Should fix#73641.
Audit uses of `span_suggestion_short` and `tool_only_span_suggestion` (`span_suggestion_hidden` is already tested with `run-rustfix`). Leave some FIXMEs for futher improvements/fixes.
r? @estebank
typeck: adding type information to projection
This commit modifies the Place as follow:
* remove 'ty' from ProjectionKind
* add type information into to Projection
* replace 'ty' in Place with 'base_ty'
* introduce 'ty()' in `Place` to return the final type of the `Place`
* introduce `ty_before_projection()` in `Place` to return the type of
a `Place` before i'th projection is applied
Closes https://github.com/rust-lang/project-rfc-2229/issues/5
