| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The Gimple names of our dyn trait objects were looking like:
const struct dyn [HIR Trait: FnLike->[C: 0 Nid: 31 Hid: 38 Lid: 13] [(FN call ), ]<Self, &isize, &isize>] & const f
This is a horrible name but useful for debugging this patch fixes this so
we have a seperate naming for generating the type. So now it looks like:
const struct dyn [FnLike<Self, &isize, &isize>] & const f
|
|
1188: Support align and packed repr layout on structs r=dafaust a=dafaust
This is a start at handling the various layout options supported by Rust, beginning with `#[repr(align(N))]` and `#[repr(packed(N))]`, on structs and tuple structs.
There are several other layout options which remain to be supported such as `#[repr(C)]`, `#[repr(transparent)]`, combinations e.g. `#[repr(C, packed(2))]`, as well as layouts on union and enum types.
Fixes: #915
Co-authored-by: David Faust <david.faust@oracle.com>
|
|
1194: Add support for transmute r=philberty a=philberty
This PR adds support for the transmute intrinsic by utilizing the convert
expression code. It also fixes a bug with our coercion rules which miss
two chances for inference variables to resolve slices and arrays.
Fixes #1130
Addresses #658
Co-authored-by: Philip Herron <philip.herron@embecosm.com>
|
|
This adds in the transmute intrisic by utilizing the convert_expression
framework we have in the backend class.
Fixes #1130
Addresses #658
|
|
|
|
1190: Fix ICE in reachability class and refactor associated types code r=philberty a=philberty
There are several fixes going on to solve these issues which overlap with one
another so it seemed best to pack them within the same PR.
The main issue for #1128 was that we did not resolve a trait when it was unused
leading to us hitting the ICE in the privacy pass. Since the type check context was
empty for the trait since it was not resolved. To fix this we needed to refactor the
trait resolver to resolve the trait as part of iterating the crate. This resulted in some
regressions in the testsuite so this is why we need the the other commits. Which
required us to finally perform the refactor specified in #1105 to fix these.
Fixes #1105 #1128 #1132
1192: Add an assertion to avoid peeking when the stack is empty r=philberty a=philberty
This will ensure we get a proper ICE instead of memory corruption/segv.
Addresses #1130
1193: Remove unused parameter caller from generating Call expressions r=philberty a=philberty
Within const context the fncontext maybe empty which in turn results in a
segv for generating const calls which will be evaluated by the const-expr
code anyway.
Addresses #1130
Co-authored-by: Philip Herron <philip.herron@embecosm.com>
|
|
1172: Resolve visibility paths r=CohenArthur a=CohenArthur
This tackles the remaining issues in #1158. ~~It also contains the commit from #1168 so you should wait for bors to merge that before reviewing it :D~~ done
The paths get resolved but their `NodeId`s are not used in the privacy visibility resolver yet.
Closes #1158
Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>
|
|
|
|
Within const context the fncontext maybe empty which in turn results in a
segv for generating const calls which will be evaluated by the const-expr
code anyway.
Addresses #1130
|
|
|
|
|
|
|
|
|
|
|
|
|
|
During type-resolution we resolve/type-check traits in a query based way.
So when we reference a trait we look it up as required but this left a case
for the privacy pass where the type-context information on the trait when
the trait was not used meant there was no type-checking performed on the
trait.
This patch adds an interface to directly resolve the trait when as we
iterate the crate so we do it as required. There is already code in the
trait resolver to check if we have already type-resolved this trait.
Fixes #1128
|
|
|
|
From PR #1086 I introduced a new setup_associated_types2 interface which
is used to ensure we handle the complex associated types in libcore slices
but this interface was inconsistant as well as the get_projected_type.
This path refactors the code base to get rid of the old
setup_associated_types interface in favour of this new one. It also removes
the get_projected_type interface which was not going to work either.
Fixes #1105
|
|
We missed a case to ensure the substitutions are equal in the is_equal
interface. This becomes important when dealing with generic associated
types since the projections could end up overlapping and we need to
differentiate them by the substitutions and monomorphization.
|
|
1189: Add missing `SimplePath`s location r=CohenArthur a=CohenArthur
Sorry to new contributors but I think I've taken all the good first issues we opened yesterday...
Closes #1179
Closes #1180
Closes #1181
Closes #1182
Necessary for #1172
Addresses #1159
Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>
|
|
1186: Refactor `ResolvePath` in its own file r=CohenArthur a=CohenArthur
Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1184: Fix bad name resolution on path with generic segments r=philberty a=philberty
This fix breaks down into two commits the first commit fixes the issue directly
then the second one fixes the regression that was introduced in the first.
The TLDR for this patch set is that when we resolve the path here:
module::transmute
The name-resolver wronly added the specified generic arguments into the canonical
path meaning that the root segment could not be name-resolved such that during
type resolution we iterate and apply the generic arguments appropriately to the root
segment.
In fixing this it introduced a regression exposing a few more complex issues with
inference variables but for a more complete explanation about that please read the
commit message from ea38a59ee8329bb7b309400a7de57d53ad7bde31
Fixes #1173
Co-authored-by: Philip Herron <philip.herron@embecosm.com>
|
|
1163: rust-session-manager: handle `crate_name` attribute r=philberty a=liushuyu
- rust-session-manager: handle `crate_name` attribute
Fix #789 properly
Co-authored-by: liushuyu <liushuyu011@gmail.com>
|
|
Signed-off-by: Zixing Liu <liushuyu011@gmail.com>
|
|
A regression was introduced in e476433c45624ec713395c85bcbd410806e90639
this was a tricky bug to fix. There are several fixes here but they all
rely on one another so in order to have a commit which does not introduce
more regressions it seems best to keep these fixes together.
In this patch we remove the check at the end of type resolution to look
for any error type nodes within the type context since this will only ever
produce false postive/duplicate errors. Since any real error will have been
emitted at the time of occurance.
We also fixed a bug in infering the types on a generic type so for example:
struct Foo<A,B>(A,B);
impl<T> Foo<T,T> { ... }
In this example the Self type on the impl block will be Foo<T,T> so in the
code for infering the arguments for the type we simply iterated each of the
generic parameter mappings and if any of them need substitution we generate
implict inference variables for them but in this case the ParamType is T
so generating one for each of these T's will introduce a stay inference
variable which we cannot infer so it will not be used. This patch keeps
a mapping inside SubstitutionRef::infer_substitions to ensure we don't
introduce any extra inference variables than required.
The final fix was around how we clone inference variables, there is a
comment explaining this but we cannot safely clone a inference variables
simply by creating a new object, inference variables are closely tied to
the type-conext so that when we infer the type to be a concrete type we
need to be able to update the reference in memory but simply cloning an
inference variable does not guarentee this to occur. This change ensures
that we create a new implict inference variable and setup the reference
and chain apropirately.
|
|
When name-resolving paths we expect the name-resolver must resolve the
root of the path. Such that a path might be
module::type::associated_function
We expect that the name resolution step must be able to resolve the
module::type
Portion of the path, it is permissive to allow everything after that to
fail name resolution as this may require generic arguments of type
inferencing to figure out which associated items are required.
The issue in this referenced issue was that the generic arguments here were
wrongly canonicalized to be part of the root path which meant the segment
could not be name-resolved allowing the type resolution system to perform
the generic specialization.
Fixes #1173
|
|
1176: Keep `SimplePath{Segment}`s in mappings r=CohenArthur a=CohenArthur
Addresses #1159
Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>
|
|
1174: Remove default location for `SimplePath`s r=CohenArthur a=CohenArthur
This removes the default argument for the locus of `SimplePath`s. Addresses #1159
There are a lot of places in the code where it is not possible to insert a "correct" location for these `SimplePath`s: namely, when creating the use statement for the standard library's prelude, or when creating the `SimplePath`s of attributes. I've left a few FIXMEs in these cases because I'm unsure about the proper course of action.
Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>
|
|
1171: Dockerfile: change base image r=philberty a=liushuyu
- Dockerfile: change base image
This commit fixes a recent Docker building error where the GLibc version mismatches.
Co-authored-by: liushuyu <liushuyu011@gmail.com>
|
|
|
|
|
|
... to match Rust container image's base image
Signed-off-by: Zixing Liu <liushuyu011@gmail.com>
|
|
1162: CI: catch malformed test cases r=philberty a=liushuyu
- catch malformed test cases and use GitHub Actions' annotation feature to mark the failures
1167: Fix nullptr when resolving the root of a path expression r=philberty a=philberty
When we resolve paths we don't have a _type_, in this scenario there is a
bug in our resolution of this generic function so this means the root_tyty
is nullptr but the offset is non zero so we return nullptr.
Addresses #1132
This test case no longer ICE's but still fails. I have a fix in progress for this
```rust
mod mem {
extern "rust-intrinsic" {
fn transmute<U, V>(_: U) -> V;
}
}
pub trait Hasher {
fn write(&mut self, bytes: &[u8]);
fn write_u16(&mut self, i: u16) {
self.write(&mem::transmute::<_, [u8; 2]>(i))
}
}
pub struct SipHasher;
impl Hasher for SipHasher {
#[inline]
fn write(&mut self, msg: &[u8]) {}
}
```
1168: ast: resolve: Move ResolveItem into its own source file r=CohenArthur a=CohenArthur
Since we need to add new functions to resolve visibilities, we might as well refactor this file before hand :)
1170: Implement macro expansion in `IfExpr`, `IfExprConseqElse`, `IfExprConseqIf`, `IfExprConseqIfLet`. r=CohenArthur a=antego
Addresses #1141. Following up on #1161.
This change adds support for the macros inside the `if` condition expressions.
Things to note:
1. Judging by my research, the `IfExprConseqIfLet` isn't used. The parser treats the syntax `let var = if ...` as a `let` expression followed by `if` expression:
2. I didn't add the macro expansion to the `IfLetExpr...` family of expressions because I wasn't able to write a test case reproducing the missing macro expansion. I've tried the following code
```rust
fn main() -> i32 {
let mut res = 0;
enum E {
X(u8),
Y(u8),
Z(u8),
}
let v = E::Y(12);
if let E::Y(n) = v {
res = 1;
}
0
}
```
which caused the compiler error
```
FAIL: rust/compile/macro43.rs (internal compiler error: in append_reference_for_def, at rust/resolve/rust-name-resolver.h:227)
```
Co-authored-by: liushuyu <liushuyu011@gmail.com>
Co-authored-by: Philip Herron <philip.herron@embecosm.com>
Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>
Co-authored-by: antego <antego@users.noreply.github.com>
|
|
1166: Support inference of generic parameters on paths behind reference's r=philberty a=philberty
We used a hack in the parser to turn simple cases such as &Foo(..) into:
BorrowExpr
CallExpr(
IdentifierExpr + <Argument-expressions>))
The IdentifierExpr here is parsed as a PathExpression but to simplify
things at the time it seemed logic to see these as identifier expressions
but this is actually a Path and we need to be careful about generic
arguments here. Identifiers are simply identifiers and must not be changed
or coherence of inference variables will become a jumble of inference
variables trying to infer one another inside purely generic code.
This patch leaves the PathInExpressions as Path's instead of trying to be
clever and turn them into identifiers.
Fixes #1165
Co-authored-by: Philip Herron <philip.herron@embecosm.com>
|
|
`IfExprConseqIfLet`.
Addresses #1141
|
|
Signed-off-by: Zixing Liu <liushuyu011@gmail.com>
|
|
|
|
1164: Add `NodeId`s to `SimplePath{Segment}`s r=CohenArthur a=CohenArthur
This is a necessary first step which addresses #1158
I am working on the visibility resolver and simple-path name resolver in parallel and will need those changes.
I'm not sure if the `has_path` method is necessary since we will have `HIR::Visibilities` in the visibility resolver, which will be desugared. Maybe I am doing this wrong and we should be working on `AST::Visibilities` instead?
Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>
|
|
When we resolve paths we don't have a _type_, in this senario there is a
bug in our resolution of this generic function so this means the root_tyty
is nullptr but the offset is non zero so we return nullptr.
Addresses #1132
|
|
We used a hack in the parser to turn simple cases such as &Foo(..) into:
BorrowExpr
CallExpr(
IdentifierExpr + <Argument-expressions>))
The IdentifierExpr here is parsed as a PathExpression but to simplify
things at the time it seemed logic to see these as identifier expressions
but this is actually a Path and we need to be careful about generic
arguments here. Identifiers are simply identifiers and must not be changed
or coherence of inference variables will become a jumble of inference
variables trying to infer one another inside purely generic code.
This patch leaves the PathInExpressions as Path's instead of trying to be
clever and turn them into identifiers.
Fixes #1165
|
|
|
|
|
|
1161: Implement macro expansion for ComparisonExpr, LazyBooleanExpr, AssignmentExpr r=CohenArthur a=antego
Following up on https://github.com/Rust-GCC/gccrs/issues/1141
Currently the macro expansion doesn't work for ComparisonExpr, LazyBooleanExpr, AssignmentExpr. To fix this, I just copied the code from the `ArithmeticOrLogicalExpr` and it seemed to work. I don't like the code duplication, happy to try refactoring it into a separate function.
Will work on the macro expansion in the `if` expressions next.
Co-authored-by: antego <antego@users.noreply.github.com>
|
|
1160: Refactor name resolver r=CohenArthur a=CohenArthur
This PR splits up the `rust-name-resolver.h` file into source and header. It also removes a bunch of `iterate_*` functions: Some were not used anymore, and some were refactored.
Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>
|
