When testing whether a default method predicates are satisfiable,
combine normalization with this check so that we also skip the
default method if normalization fails. Fixes#23485.
r? @nrc (I tried to address your nit from before as well)
This commit removes parser support for `extern crate "foo" as bar` as the
renamed crate is now required to be an identifier. Additionally this commit
enables hard errors on crate names that contain hyphens in them, they must now
solely contain alphanumeric characters or underscores.
If the crate name is inferred from the file name, however, the file name
`foo-bar.rs` will have the crate name inferred as `foo_bar`. If a binary is
being emitted it will have the name `foo-bar` and a library will have the name
`libfoo_bar.rlib`.
This commit is a breaking change for a number of reasons:
* Old syntax is being removed. This was previously only issuing warnings.
* The output for the compiler when input is received on stdin is now `rust_out`
instead of `rust-out`.
* The crate name for a crate in the file `foo-bar.rs` is now `foo_bar` which can
affect infrastructure such as logging.
[breaking-change]
Refactored code so that the drop-flag values for initialized
(`DTOR_NEEDED`) versus dropped (`DTOR_DONE`) are given explicit names.
Add `mem::dropped()` (which with `DTOR_DONE == 0` is semantically the
same as `mem::zeroed`, but the point is that it abstracts away from
the particular choice of value for `DTOR_DONE`).
Filling-drop needs to use something other than `ptr::read_and_zero`,
so I added such a function: `ptr::read_and_drop`. But, libraries
should not use it if they can otherwise avoid it.
Fixes to tests to accommodate filling-drop.
The reassignment checker effectively only checks whether the last
assignment in a body affects the discriminant, but it should of course
check all the assignments.
Fixes#23698
The reassignment checker effectively only checks whether the last
assignment in a body affects the discriminant, but it should of course
check all the assignments.
Fixes#23698
The compiler will now issue a warning for crates that have syntax of the form
`extern crate "foo" as bar`, but it will still continue to accept this syntax.
Additionally, the string `foo-bar` will match the crate name `foo_bar` to assist
in the transition period as well.
This patch will land hopefully in tandem with a Cargo patch that will start
translating all crate names to have underscores instead of hyphens.
cc #23533
The compiler will now issue a warning for crates that have syntax of the form
`extern crate "foo" as bar`, but it will still continue to accept this syntax.
Additionally, the string `foo-bar` will match the crate name `foo_bar` to assist
in the transition period as well.
This patch will land hopefully in tandem with a Cargo patch that will start
translating all crate names to have underscores instead of hyphens.
cc #23533
The primary motivation here is to sidestep #19032 -- for a time, I thought that we should improve coherence or otherwise extend the language, but I now think that any such changes will require more time to bake. In the meantime, inheritance amongst the fn traits is both logically correct *and* a simple solution to that obstacle. This change introduces inheritance and modifies the compiler so that it can properly generate impls for closures and fns.
Things enabled by this PR (but not included in this PR):
1. An impl of `FnMut` for `&mut F` where `F : FnMut` (https://github.com/rust-lang/rust/issues/23015).
2. A better version of `Thunk` I've been calling `FnBox`.
I did not include either of these in the PR because:
1. Adding the impls in 1 currently induces a coherence conflict with the pattern trait. This is interesting and merits some discussion.
2. `FnBox` deserves to be a PR of its own.
The main downside to this design is (a) the need to write impls by hand; (b) the possibility of implementing `FnMut` with different semantics from `Fn`, etc. Point (a) is minor -- in particular, it does not affect normal closure usage -- and could be addressed in the future in many ways (better defaults; convenient macros; specialization; etc). Point (b) is unfortunate but "just a bug" from my POV, and certainly not unique to these traits (c.f. Copy/Clone, PartialEq/Eq, etc). (Until we lift the feature-gate on implementing the Fn traits, in any case, there is room to correct both of these if we find a nice way.)
Note that I believe this change is reversible in the future if we decide on another course of action, due to the feature gate on implementing the `Fn` traits, though I do not (currently) think we should reverse it.
Fixes#18835.
r? @nrc
This permits all coercions to be performed in casts, but adds lints to warn in those cases.
Part of this patch moves cast checking to a later stage of type checking. We acquire obligations to check casts as part of type checking where we previously checked them. Once we have type checked a function or module, then we check any cast obligations which have been acquired. That means we have more type information available to check casts (this was crucial to making coercions work properly in place of some casts), but it means that casts cannot feed input into type inference.
[breaking change]
* Adds two new lints for trivial casts and trivial numeric casts, these are warn by default, but can cause errors if you build with warnings as errors. Previously, trivial numeric casts and casts to trait objects were allowed.
* The unused casts lint has gone.
* Interactions between casting and type inference have changed in subtle ways. Two ways this might manifest are:
- You may need to 'direct' casts more with extra type information, for example, in some cases where `foo as _ as T` succeeded, you may now need to specify the type for `_`
- Casts do not influence inference of integer types. E.g., the following used to type check:
```
let x = 42;
let y = &x as *const u32;
```
Because the cast would inform inference that `x` must have type `u32`. This no longer applies and the compiler will fallback to `i32` for `x` and thus there will be a type error in the cast. The solution is to add more type information:
```
let x: u32 = 42;
let y = &x as *const u32;
```
The method with which backwards compatibility was retained ended up leading to
documentation that rustdoc didn't handle well and largely ended up confusing.
For the rust-call ABI, the last function argument is a tuple that gets
untupled for the actual call. For bare functions using this ABI, the
code has access to the tuple, so we need to tuple the arguments again.
But closures can't actually access the tuple. Their arguments map to the
elements in the tuple. So what we currently do is to tuple the arguments
and then immediately untuple them again, which is pretty useless and we
can just omit it.
This is a [breaking-change]. When indexing a generic map (hashmap, etc) using the `[]` operator, it is now necessary to borrow explicitly, so change `map[key]` to `map[&key]` (consistent with the `get` routine). However, indexing of string-valued maps with constant strings can now be written `map["abc"]`.
r? @japaric
cc @aturon @Gankro
This fixes a bug in LLVM IR generation for in-line assembly where Rust would always use the host clobbers instead of target clobbers.
I also took this opportunity to clean/simplify the ```trans_inline_asm``` function.
This is my first Rust pull request; please let me know if I'm missing anything.
This commit:
* Introduces `std::convert`, providing an implementation of
RFC 529.
* Deprecates the `AsPath`, `AsOsStr`, and `IntoBytes` traits, all
in favor of the corresponding generic conversion traits.
Consequently, various IO APIs now take `AsRef<Path>` rather than
`AsPath`, and so on. Since the types provided by `std` implement both
traits, this should cause relatively little breakage.
* Deprecates many `from_foo` constructors in favor of `from`.
* Changes `PathBuf::new` to take no argument (creating an empty buffer,
as per convention). The previous behavior is now available as
`PathBuf::from`.
* De-stabilizes `IntoCow`. It's not clear whether we need this separate trait.
Closes#22751Closes#14433
[breaking-change]
impls.
This requires:
1. modifying trait selection a bit so that when we synthesize impls for
fn pointers and closures;
2. adding code to trans so that we can synthesize a `FnMut`/`FnOnce`
impl for a `Fn` closure and so forth.
Boolean values and small aggregates have a different type in args/allocas than
in SSA values but the intrinsics for volatile and atomic ops were
missing the necessary casts to handle that.
Fixes#23550
For the rust-call ABI, the last function argument is a tuple that gets
untupled for the actual call. For bare functions using this ABI, the
code has access to the tuple, so we need to tuple the arguments again.
But closures can't actually access the tuple. Their arguments map to the
elements in the tuple. So what we currently do is to tuple the arguments
and then immediately untuple them again, which is pretty useless and we
can just omit it.
After this patch code like `let ref a = *"abcdef"` doesn't cause ICE anymore.
Required for #23121
There are still places in rustc_trans where pointers are always assumed to be thin. In particular, #19064 is not resolved by this patch.
The method with which backwards compatibility was retained ended up leading to
documentation that rustdoc didn't handle well and largely ended up confusing.
Boolean values and small aggregates have a different type in
args/allocas than in SSA values but the intrinsics for volatile and
atomic ops were missing the necessary casts to handle that.
Fixes#23550
This includes a slight refactoring of the `cast_shift_rhs` and related
functions in `trans::base`, so that I can call them from much later in
the compiler's control flow (so that we can clearly dilineate where
automatic conversions of the RHS occur, versus where we check it).
The rhs-checking and fallback-masking is generalized to 8- and 16-bit
values, and the fallback-masking is turned on unconditionally.
Fix#10183.
Is this a [breaking-change]? I would argue it is not; it only adds a
strict definition to what was previously undefined behavior; however,
there might be code that was e.g. assuming that `1_i8 << 17` yields 0.
(This happens in certain contexts and at certain optimization levels.)
