This does not,
I still can't reproduce it - but it is still occurring with the Glew
header file!
On 12/01/15 15:31, Corbat Thomas wrote:
Hi Alec
I think I can reproduce your problem with a
small example:
myStruct.h:
---------------------------------
#ifndef MYSTRUCT_HPP_
#define MYSTRUCT_HPP_
#define MACRO 1
#include "someHeader.h"
struct S {
int foo();
};
inline int S::foo() {
int anInt = MACRO;
return anInt;
}
#endif /* MYSTRUCT_HPP_ */
---------------------------------
Use toggle on foo(). See the newly created
myStruct.cpp:
---------------------------------
#include "myStruct.h"
int S::foo() {
return anInt;
}
---------------------------------
Could you please check if that is the problem
you observe?
Kind Regards
Thomas
The steps to reproduce are not portable!
I mentioned I was using glew. This tries to be portable yes
but it isn't. The fact that there's no exception dumped out
from Eclipse means it's some really nasty deep issue
(probably) and someone who knows the parser and the toggle
function bit might have any hints at how I can consistently
reproduce this.
By taken seriously I mean: "My IDE is deleting swaths of code
without any indication anything has gone wrong, help me find
out why and fix it" - this should be taken seriously, a bug
which pops up saying "Hey, can't do that for some weird
reason" is fine, it does this silently. Hence the "urgent".
Steps to reproduce:
1) Include glew
2) Create a header file
3) Write a class with a method that uses ANYTHING that stars
with GL
4) Press alt+shift+t (I think? It's sort of muscle memory now)
- just toggle the function
5) Repeat 4 again (so it moves the method to a .cpp file)
6) Observe failure.
We all know Eclipse is fine with macros, so this bug is not
"Macros cause failure" and there is no information to help me
find out why (hence asking you lot!) there's no error report,
exceptions, nothing.
We all know that "include glew" is not a portable way to
reproduce, do you want me to copy and paste a 15mb (ish) file
here? I am leaning towards "big files=bad" because EVEN THE
CONSTANTS don't carry forward, a line that reads #define
GL_VERTEX_SHADER 0x83b2 (or whatever) should work, defines
work fine with Eclipse but they fail, if you mouse over the
constant Eclipse expands it correctly!
So what is going on? Without any sort of error log or details
I can only speculate. Hence asking you. What could be
happening that makes Eclipse erase the function body when
moving something with a macro from a large file? Is it even
the large file part? Exactly.
Alec
On 11/01/15 02:33, Doug Schaefer wrote:
More seriously by who? I’m sorry you’re
seeing this but I’ve never heard a report of this before so
it’s curious why you’re seeing it. Again, please create a
bug report with all the steps you’ve taken to reproduce it.
And it would be awesome if you could contribute a fix. This
is an open community with only a handful of contributors. We
need your help.
I'm trying to debug it, I thought
this'd be taken more seriously! It's deleting swaths of
code because they contain macros silently, that's a big
issue.
I usually have code that contains macros, I usually use
this and it works, the only thing that's changed this
time is that it is from a huge file.
Alec
On 10/01/15 22:56, Sergey Prigogin wrote:
On Sat, Jan 10, 2015 at 11:28
AM, Alec Teal <a.teal@xxxxxxxxxxxxx>
wrote:
I think it is linked to
macros, or macros from a huge file.
There's no error coming from eclipse (I ran it
in a terminal) there are no exceptions that show
up.
What should I be looking for more than that?
I've reproduced it with glew.
I meant a reasonable size
self contained reproduction case that you can
share outside your organization. Alternatively,
you can debug the problem yourself.
On 10/01/15 19:24,
Sergey Prigogin wrote:
On Sat, Jan 10,
2015 at 11:12 AM, Alec Teal <a.teal@xxxxxxxxxxxxx>
wrote:
I've found out
more.
glew.h is a MASSIVE file, so much
so I altered scaling settings when
I opened it. I've also increased
the indexer's available memory and
rebuilt the index.
EclipseCDT is able to tell me the
value of macros.
It turns out any method that uses
any of these macros (I would guess
any, I've not used them all!)
won't be moved correctly.
Does this help?
No, it does
not. Please try to produce a
reproducible case.
Alec
OH! I've reproduced it now
across installs and machines!
Alec
On 10/01/15 19:09, Doug
Schaefer wrote:
I
guess because it¹s doing it
all the time but only on
you¹re machine. Can
you reproduce it on another
one? What else do you have
installed? Things
like that.
Doug
On 2015-01-10, 10:40 AM,
"Alec Teal" <a.teal@xxxxxxxxxxxxx>
wrote:
It's now
doing it with everything.
I don't know how to say
"here's how you reproduce
this" because it's now
doing it all the time!
Alec
On 10/01/15 12:04, Alec Teal
wrote:
I'm
having trouble with that and
there are so many things
that could
be causing this, does anyone
that knows this part of CDT
have any idea
how to start narrowing it
down?
Also seriously Nate, I get
that this is a bug - it's
destroying code :P
As I said before "I do not
know what is causing it" and
it took me a
while to notice it.
Alec
On 10/01/15 07:15, Nathan
Ridge wrote:
What's
causing it?
Please
file a bug report with a
complete example so that we
can
reproduce the problem and
investigate it.
Thanks,
Nate
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery
options, retrieve your
password, or
unsubscribe from this list,
visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery
options, retrieve your
password, or
unsubscribe from this list,
visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery
options, retrieve your
password, or unsubscribe
>from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery
options, retrieve your
password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery
options, retrieve your
password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|