This reverts commit a0efd3a3d9.
This commit caused a lot of unintended breakage for many Cargo builds. The problem is that Cargo compiles build scripts with `-C prefer-dynamic`, so the standard library is always dynamically linked and hence any imports need to be marked with `dllimport`. Dependencies of build scripts, however, were compiled as rlibs and did not have their imports tagged with `dllimport`, so build scripts would fail to link.
While known that this situation would break, it was unknown that it was a common scenario in the wild. As a result I'm just reverting these heuristics for now.
Instead of bar/baz, use valid/invalid as default methods. This
illustrates why you might want default methods, and shows that you can
call other trait methods from a default method.
r? @steveklabnik
It's deprecated and unsafe, so we shouldn't be encouraging people to use
it. Move it to `std:🧵:scoped` instead, since it's still useful
information to anyone who is using the API.
`Rc::new(RefCell::new(x)): Rc<RefCell<Trait>>` should not mean `RefCell::new(x): RefCell<Trait>`.
The latter is impossible, as an rvalue can't have an unsized type.
We were already handling unsized argument hints, but not when dealing with unsized structures.
It's deprecated and unsafe, so we shouldn't be encouraging people to use
it. Move it to `std:🧵:scoped` instead, since it's still useful
information to anyone who is using the API.
Fixes#26689
This PR tries to clarify uses of "character" where it means "code point" or "UTF-8 sequence", which are almost, but not quite the same. Edge cases added to some examples to demonstrate this.
However, I've kept use of the term "code point" instead of "Unicode scalar value", because in UTF-8 they're the same, and "code point" is more widely known.
This does two things:
* removes ast::LocalSource, where only one variant was used because for-loop expansion has changed. One reason that this slipped into here is because the code in `check_local` which checks for `LocalSource::LocalFor` would report the same error as in `check_exhaustive` while using the wrong error code (E0005 instead of E0297).
* silences the warning about already used diagnostic code E0005 (fixes#27279)
passes `make check` locally.
This PR completes [RFC 213](https://github.com/rust-lang/rfcs/blob/master/text/0213-defaulted-type-params.md) by allowing default type parameters to influence inference. This is almost certainly a breaking change due to interactions between default type parameters and the old fallback algorithm used for integral and floating point literals.
The error messages still require polish but I wanted to get early review and feedback from others on the the changes, error messages, and test cases. I also imagine we will want to run anywhere from 1-3 versions of this on crater and evaluate the impact, and it would be best to get that ball rolling.
The only outstanding issue I'm aware of is that type alias defaults don't work. It seems this may require significant restructuring, since during inference type aliases have already been expanded. @nikomatsakis might be able to provide some clarity here.
r? @nikomatsakis
cc @eddyb @Gankro @aturon @brson
`LocalSource` indicated wether a let binding originated from for-loop desugaring to enable specialized error messages, but for-loop expansion has changed and this is now achieved through `MatchSource::ForLoopDesugar`.
The algorithm was not correctly detecting conflicts after moving
defaults into TypeVariableValue. The updated algorithm
correctly detects and reports conflicts with information about
where the conflict occured and which items the defaults were
introduced by. The span's for said items are not being correctly
attached and still need to be patched.
