By RFC1214:
Before calling a fn, we check that its argument and return types are WF. This check takes place after all higher-ranked lifetimes have been instantiated. Checking the argument types ensures that the implied bounds due to argument types are correct. Checking the return type ensures that the resulting type of the call is WF.
The previous code only checked the trait-ref, which was not enough
in several cases.
As this is a soundness fix, it is a [breaking-change].
Fixes#28609
This PR closes out #28716 and #28735 by making two changes to the compiler:
1. The `--emit` flag to the compiler now supports the ability to specify the output file name of a partuclar emit type. For example `--emit dep-info=bar.d,asm=foo.s,link` is now accepted.
2. The dep-info emission now emits a dummy target for all input file names to protect against deleted files.
These common traits were left off originally by accident from these smart
pointers, and a past attempt (#26008) to add them was later reverted (#26160)
due to unexpected breakge (#26096) occurring. The specific breakage in worry is
the meaning of this return value changed:
let a: Box<Option<T>> = ...;
a.as_ref()
Currently this returns `Option<&T>` but after this change it will return
`&Option<T>` because the `AsRef::as_ref` method shares the same name as
`Option::as_ref`. A [crater report][crater] of this change, however, has shown
that the fallout of this change is quite minimal. These trait implementations
are "the right impls to add" to these smart pointers and would enable various
generalizations such as those in #27197.
[crater]: https://gist.github.com/anonymous/0ba4c3512b07641c0f99
This commit is a breaking change for the above reasons mentioned, and the
mitigation strategies look like any of:
Option::as_ref(&a)
a.as_ref().as_ref()
(*a).as_ref()
Previously only keyup event was looked at, which meant that pasting, cutting and
otherwise changing the input without typing would not catch any updates to the
search query.
Please correct me if I confused something but the documentation for ```into_ptr``` and ```into_raw``` of ```CString``` seem to be swapped as the docs for ```into_ptr``` mentions ```into_raw``` and vice versa.
Update: I actually meant ```into_ptr``` and ```into_raw``` NOT ```from_*```
The behavior here isn't really ideal, but we can't really do much better
given the current state of constant evaluation.
The changes to ExprUseVisitor are to avoid a compile error; apparently
that bit of code is extremely sensitive to changes in other areas of the
compiler.
Fixes#28670, and probably a bunch of duplicates.
As described in https://github.com/rust-lang/rfcs/pull/1298, the idea here is to make DefIds independent of changes to the content of other items. They are also *mostly* independent from ordering, so e.g. reordering two functions will change the defids, but it will not change the paths that they expand into (but this is not the case for some things, such as impls).
This is a major refactoring, so I did it in slices. The final commit is in some sense The Big One where most of the work is done. The earlier commits just pave the way by gradually refactoring accesses to the `node` field.
This is a [breaking-change] for plugin authors. The things you need to do to migrate your code are as follows:
1. For local def-ids, rather than do `def_id.node`, call `tcx.map.as_local_node_id(def_id)`.
2. To construct a local def-id, call `tcx.map.local_def_id(node_id)`.
3. Note that you cannot make def-ids for any node, but only for "definitions" -- which include all items, as well as a number of other things, but not e.g. arbitrary expressions.
4. You can get the path to a def-id by calling `tcx.def_path(def_id)`.
One thing that is NOT part of this PR, but which I plan do in a follow-up, is converting uses of the existing `with_path` API to use `def_path`, which is basically the same.
r? @eddyb (or @nrc)
