| Age | Commit message (Collapse) | Author | Lines |
|---|
|
(compiler front-ends).
|
|
|
|
refactor: use shorthand fields
refactor: use shorthand for single fields everywhere (excluding tests).
|
|
|
|
rustc: Tweak filenames encoded into metadata
This commit is a fix for #54408 where on nightly right now whenever
generics are inlined the path name listed for the inlined function's
debuginfo is a relative path to the cwd, which surely doesn't exist!
Previously on beta/stable the debuginfo mentioned an absolute path which
still didn't exist, but more predictably didn't exist.
The change between stable/nightly is that nightly is now compiled with
`--remap-path-prefix` to give a deterministic prefix to all
rustc-generated paths in debuginfo. By using `--remap-path-prefix` the
previous logic would recognize that the cwd was remapped, causing the
original relative path name of the standard library to get emitted. If
`--remap-path-prefix` *wasn't* passed in then the logic would create an
absolute path name and then create a new source file entry.
The fix in this commit is to apply the "recreate the source file entry
with an absolute path" logic a bit more aggresively. If the source
file's name was remapped then we don't touch it, but otherwise we always
take the working dir (which may have been remapped) and then join it to
the file to ensure that we process all relative file names as well.
The end result is that the standard library should have an absolute path
for all file names in debuginfo (using our `--remap-path-prefix`
argument) as it does on stable after this patch.
Closes #54408
|
|
|
|
This commit is a fix for #54408 where on nightly right now whenever
generics are inlined the path name listed for the inlined function's
debuginfo is a relative path to the cwd, which surely doesn't exist!
Previously on beta/stable the debuginfo mentioned an absolute path which
still didn't exist, but more predictably didn't exist.
The change between stable/nightly is that nightly is now compiled with
`--remap-path-prefix` to give a deterministic prefix to all
rustc-generated paths in debuginfo. By using `--remap-path-prefix` the
previous logic would recognize that the cwd was remapped, causing the
original relative path name of the standard library to get emitted. If
`--remap-path-prefix` *wasn't* passed in then the logic would create an
absolute path name and then create a new source file entry.
The fix in this commit is to apply the "recreate the source file entry
with an absolute path" logic a bit more aggresively. If the source
file's name was remapped then we don't touch it, but otherwise we always
take the working dir (which may have been remapped) and then join it to
the file to ensure that we process all relative file names as well.
The end result is that the standard library should have an absolute path
for all file names in debuginfo (using our `--remap-path-prefix`
argument) as it does on stable after this patch.
Closes #54408
|
|
|
|
|
|
This reverts commit d02a5ffaed9c395ae62ee12d0f4e04946c62edb1.
|
|
|
|
fixes the *first* false positive reported in #53964
|
|
This completely splits the IS_NON_EXHAUSTIVE flag. No functional
changes intended.
|
|
Structs and enums can both be non-exhaustive, with a very different
meaning. This PR splits `is_non_exhaustive` to 2 separate functions - 1
for structs, and another for enums, and fixes the places that got the
usage confused.
Fixes #53549.
|
|
Found by clippy.
|
|
Ty{Adt|Array|Slice|RawPtr|Ref|FnDef|FnPtr|Dynamic|Closure|Generator|GeneratorWitness|Never|Tuple|Projection|Anon|Infer|Error}
|
|
Rollup of 17 pull requests
Successful merges:
- #53030 (Updated RELEASES.md for 1.29.0)
- #53104 (expand the documentation on the `Unpin` trait)
- #53213 (Stabilize IP associated constants)
- #53296 (When closure with no arguments was expected, suggest wrapping)
- #53329 (Replace usages of ptr::offset with ptr::{add,sub}.)
- #53363 (add individual docs to `core::num::NonZero*`)
- #53370 (Stabilize macro_vis_matcher)
- #53393 (Mark libserialize functions as inline)
- #53405 (restore the page title after escaping out of a search)
- #53452 (Change target triple used to check for lldb in build-manifest)
- #53462 (Document Box::into_raw returns non-null ptr)
- #53465 (Remove LinkMeta struct)
- #53492 (update lld submodule to include RISCV patch)
- #53496 (Fix typos found by codespell.)
- #53521 (syntax: Optimize some literal parsing)
- #53540 (Moved issue-53157.rs into src/test/ui/consts/const-eval/)
- #53551 (Avoid some Place clones.)
Failed merges:
r? @ghost
|
|
Remove LinkMeta struct
Fixes #53291
|
|
The Great Generics Generalisation: HIR Followup
Addresses the final comments in #48149.
r? @eddyb, but there are a few things I have yet to clean up. Making the PR now to more easily see when things break.
cc @yodaldevoid
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is a clippy-breaking change.
|
|
|
|
|
|
|
|
|
|
|
|
This commit upgrades the main LLVM submodule to LLVM's current master branch.
The LLD submodule is updated in tandem as well as compiler-builtins.
Along the way support was also added for LLVM 7's new features. This primarily
includes the support for custom section concatenation natively in LLD so we now
add wasm custom sections in LLVM IR rather than having custom support in rustc
itself for doing so.
Some other miscellaneous changes are:
* We now pass `--gc-sections` to `wasm-ld`
* The optimization level is now passed to `wasm-ld`
* A `--stack-first` option is passed to LLD to have stack overflow always cause
a trap instead of corrupting static data
* The wasm target for LLVM switched to `wasm32-unknown-unknown`.
* The syntax for aligned pointers has changed in LLVM IR and tests are updated
to reflect this.
* The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug]
Nowadays we've been mostly only upgrading whenever there's a major release of
LLVM but enough changes have been happening on the wasm target that there's been
growing motivation for quite some time now to upgrade out version of LLD. To
upgrade LLD, however, we need to upgrade LLVM to avoid needing to build yet
another version of LLVM on the builders.
The revision of LLVM in use here is arbitrarily chosen. We will likely need to
continue to update it over time if and when we discover bugs. Once LLVM 7 is
fully released we can switch to that channel as well.
[llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382
|
|
r=scalexm
Move self trait predicate to items
This is a "reimagination" of @tmandry's PR #50183. The main effect is described in this comment from one of the commits:
---
Before we had the following results for `predicates_of`:
```rust
trait Foo { // predicates_of: Self: Foo
fn bar(); // predicates_of: Self: Foo (inherited from trait)
}
```
Now we have removed the `Self: Foo` from the trait. However, we still
add it to the trait ITEM. This is because when people do things like
`<T as Foo>::bar()`, they still need to prove that `T: Foo`, and
having it in the `predicates_of` seems to be the cleanest way to
ensure that happens right now (otherwise, we'd need special case code
in various places):
```rust
trait Foo { // predicates_of: []
fn bar(); // predicates_of: Self: Foo
}
```
However, we sometimes want to get the list of *just* the predicates
truly defined on a trait item (e.g., for chalk, but also for a few
other bits of code). For that, we define `predicates_defined_on`,
which does not contain the `Self: Foo` predicate yet, and we plumb
that through metadata and so forth.
---
I'm assigning @eddyb as the main reviewer, but I thought I might delegate to scalexm for this one in any case. I also want to post an alternative that I'll leave in the comments; it occurred to me as I was writing. =)
r? @eddyb
cc @scalexm @tmandry @leodasvacas
|
|
This new query returns only the predicates *directly defined* on an
item (in contrast to the more common `predicates_of`, which returns
the predicates that must be proven to reference an item). These two
sets are almost always identical except for traits, where
`predicates_of` includes an artificial `Self: Trait<...>` predicate
(basically saying that you cannot use a trait item without proving
that the trait is implemented for the type parameters).
This new query is only used in chalk lowering, where this artificial
`Self: Trait` predicate is problematic. We encode it in metadata but
only where needed since it is kind of repetitive with existing
information.
Co-authored-by: Tyler Mandry <tmandry@gmail.com>
|
|
It was pointed out in review that the glob-exported
underscore-suffixed convention for `Spanned` HIR nodes is no longer
preferred: see February 2016's #31487 for AST's migration away from
this style towards properly namespaced NodeKind enums.
This concerns #51968.
|
|
There are at least a couple (and plausibly even three) diagnostics that
could use the spans of visibility modifiers in order to be reliably
correct (rather than hacking and munging surrounding spans to try to
infer where the visibility keyword must have been).
We follow the naming convention established by the other `Spanned` HIR
nodes: the "outer" type alias gets the "prime" node-type name, the
"inner" enum gets the name suffixed with an underscore, and the variant
names are prefixed with the prime name and `pub use` exported from here
(from HIR).
Thanks to veteran reviewer Vadim Petrochenkov for suggesting this
uniform approach. (A previous draft, based on the reasoning that
`Visibility::Inherited` should not have a span, tried to hack in a named
`span` field on `Visibility::Restricted` and a positional field on
`Public` and `Crate`. This was ... not so uniform.)
|
|
|
|
Namely: labels, type parameters, bindings in patterns, parameter names in functions without body.
All of these do not need hygiene after lowering to HIR, only span locations.
|
|
|
|
|
|
This is gated on edition 2018 & the `async_await` feature gate.
The parser will accept `async fn` and `async unsafe fn` as fn
items. Along the same lines as `const fn`, only `async unsafe fn`
is permitted, not `unsafe async fn`.The parser will not accept
`async` functions as trait methods.
To do a little code clean up, four fields of the function type
struct have been merged into the new `FnHeader` struct: constness,
asyncness, unsafety, and ABI.
Also, a small bug in HIR printing is fixed: it previously printed
`const unsafe fn` as `unsafe const fn`, which is grammatically
incorrect.
|
|
|
|
|
|
|
