(I've looked far and wide but I can't even find anyone having the same problem, not to mention a fix or anything. Closest is this thread which just announces the feature...)
The way it currently works for me, the VS2019 code lens integration of P4VS (for C++ at least) is almost completely pointless. Each function has an indicator added, but the information in each is identical - namely the change history of the entire file:
According to this Microsoft article, I would expect to either get function-level change information that pertains only to that function or a single change summary of the file at the bottom of the editor. But instead I get the worst combination of both.
I'm mainly surprised that I can't find anyone else talking about this, so I assume something is misconfigured on my part. Can't find anything in the configuration options though...
Is this just a bad implementation by Perforce or is something wrong on my end?
I have just found out that it can be turned off by Visual Studio options.
How to turn off CodeLens-References
Text Editor > All Languagues > CodeLens
Related
A little configuration information to start:
Xcode 13
Qt 5.15.5
iOS 14.7.1 (18G82) (I'm running on a device, not a
simulator)
Host MacOS Big Sur 11.6
I'm debugging a large Qt app, all written in C++, except for the necessary few files to make it work in iOS (so it's really an Objective-C++ app with an enormous amount of native C++ linked to it, everything of Qt it needs). I have a break point within the LoadApplication method - Qt has been built from source for development (that is, in debug configuration with symbols). There are a number of native Qt QUrl objects whose values I'd like to inspect. I have successfully installed lldbbridge.py, but I think the problem may be unrelated to that, because I saw it when I was using other tricks to see the data without the bridge. There is a method called toString on the QUrl class that produces a text representation of the URL (and another called toDisplayString that may be more human readable). These methods produce (of course) QString objects. So here are the failure modes:
First the bridge should be helping me to inspect the QUrl and all I see are the raw object descriptions that hide all the private interfaces. It isn't.
before I installed the lldbbridge.py script, I was able to view some of these objects (local variables, but not parameters), using code like expr url.toString().toStdString().c_str(). It still might work on local variables, but I would really like to be able to inspect parameters as well.
the error feedback I get is
error: <lldb wrapper prefix>:21198:9: module 'std' not found
#import std;
~~~~~~~^~~
this is a pretty legit error, because I have scoured my system and the internet for evidence of this std.framework whose existence is implied, and cannot find it, though its name suggests that it would be an assist to Objective-C or Swift to deal with std::string and the like. Possibly it was a thing in Xcode 12 that has been dropped in Xcode 13, but if so, it has no footprint on the web that I can find. Still, presumably Qt 5.15.5's lldbbridge.py was compiled and run and against it at some point in the recent past.
this isn't the only trick that doesn't work when inspecting a QString, with or without the bridge. I also tried expr (const wchar_t*)url.toString().toUtf16() and expr (const char*)url.toString().toUtf8() and so forth. The same error feedback results, complaining about the mysterious "std" framework or module.
and don't get too hung up on QUrl objects, because I get the same result with other QStrings.
one more symptom: if I do an expr #import std; in the lldb command line, it appears to work. That is, it gives no error feedback and appears to complete. This just makes the world weirder, because if exists, it must be hiding somewhere inside Xcode's contents, but I've done file searches in there, and see no evidence of such a thing. And if it does exist, why is the lldb wrapper prefix giving me grief? Could the wrapper be underspecified in terms of framework search paths, but the lldb command line not?
So as if it's not too obvious, here are my questions (besides WTF???):
Am I the first to see this? I've seen some forum talk about string inspection no longer working for others in Xcode 13 lldb, but the specific failure mode is different. Anyone else see this?
Does anyone have any idea about this mysterious "std" framework or module? Could its functionality have been sucked up into some other module or framework for Xcode 13?
Any ideas about work-arounds that I haven't thought of? I'm not a complete lldb novice, but I'm not an expert either.
I'd like to turn up the log levels look at those for clues, but I've never used that feature before, and I don't really even know where to FIND the logs.
I notice that the feedback suggests that there are at least 21198 lines in this "wrapper" BEFORE we get to the failing import statement. Seems a little excessive to wrap a request to view the contents of a string. Perhaps the whole wrapper is corrupted in some way. Any thoughts on how to test that hypothesis? How about a way to inspect the contents of the wrapper prefix itself?
Could the #import std; be a red herring and just co-lateral damage in some other unrelated failure mode? It's tempting to imagine it's some kind of std library support thing, but I don't want to assume too much at this point.
one more things about "std", whatever it is - lldb is super dynamic. It's always compiling inline code on-the-fly to support its functionality. That's the whole llvm magic. Is it possible it exists only as some inline text within lldb's source? And again, if so, why is it only selectively available?
Well, that's my nightmare. Unless my setup is horribly corrupted in some way and it's my unique curse, I'm sure this problem will show up for others, so cogent answers will make you a hero. Any pointers are appreciated. Thanks.
I'm using VS2012 and I'm quite happy with it. But the problem is, whem I'm coding in C++, that the syntax highlighting is turning off an on all over again. Sometimes, the highlighting is off and I have to reload the file. Also, it highlighting is quite slow.
Does anyone know how to fix it?
I know this is a while ago but I have had this same problem appearing randomly until just now.
It would disable when the last line in a file was a single line comment. (// blah blah). As soon as i removed that the text highlighting worked again!
Edit: In this answer I assume that your problem description is correct. In other words, I'm assuming that occasionally C++ highlighting is working, and the other times the text appears as plain text: completely black and white.
My guess is you are using an extension which modifies or replaces the way Visual Studio highlights C++ code. Try temporarily disabling all of your extensions and checking again if the editor is working. Some extensions might have the Disable button disabled; in that case you'll need to uninstall the extension for this test (possibly through Control Panel → Programs and Features).
As an example of one common extension that completely replaces the C++ highlighter is Visual Assist. However, I do not personally use that product and I haven't heard of any specific problems with it of this nature. I am merely mentioning it as an example of an extension that completely changes the behavior of Visual Studio in regards to syntax highlighting of C++ code.
For me, highlighting always stops working when the first visible line in the editor begins with the characters '//' and I trigger reparsing somehow (CTRL + S for instance).
Highlighting always works fine when the first visible line in the editor begins with anything else, even with a whitespace, and I trigger reparsing somehow.
I could indent all my comments and never experience this problem, but now that I know about it, it's not so annoying anymore, so I let it be.
This is a bug in Visual Studio 2012:
https://connect.microsoft.com/VisualStudio/feedback/details/760154/syntax-highlighting-sometimes-not-working
If you're using only Intellisense, you may go to Edit->Intellisense->Toggle Completion Mode (or hit Ctrl + Alt + Space), play with it and see if it works (maybe you've pressed this combination of keys by accident).
I've also installed Update 3 and haven't had any problems since. Who knows..
I had the same problem. Disabling the extentions sadly did not work for me.
After searching around and realizing that it only happened on larger files,
I got it to work by turning harware acceleration off.
Tools->Options...->Environment->General
*Automatically adjust [...] (off)
*Use hardware graphics acceleration (off)
In my case, it turned out that a large block of code (a 200+ line method) was commented out with // starting in the first column, and this was causing the syntax coloring not to work. I changed the commenting delineation to /* ... */ for that method and all of the syntax coloring was fixed.
Personally, I found that things like:
#if 0// bla-bla
mess up syntax highlighting badly. The solution that works for is to put a space before a comment, like so:
#if 0 // bla-bla
I installed Visual Studio 2012 Update 3 yesterday and started experiencing the exact same behavior described in the original post. Based on some suggestions in this thread, I took at look at my extensions, and disabling AllMargins fixed the issue. I've since re-enabled AllMargins and everything appears to be working as it should.
Try disabling and re-enabling any of your extensions; hopefully that will fix the issue for you.
I am using PC-Lint for my C++ project.
Is there a way to switch off all error and warning messages by default, so I can then reintroduce the required messages explicitly?
I have read the chapter of the PC-Lint manual entitled "Error Inhibition Options" and the best I could find was setting the wLevel to -w0 No messages (except for fatal errors)
Yes, it is possible, you can simply use -e* or -w0. However, the manual truly states (Chapter 16. Living with Lint):
DO NOT simply suppress all warnings with something
like: -e* or -w0 as this can disguise hard errors and make subsequent diagnosis very difficult.
So, yes, you can use it if your code is basically cleaned, and you want to review recent changes for a certain set of messages. But if you want to start cleaning your code, and are swamped with messages because of the default warning level -w3, I suggest to start using -w1, and resolve all issues there; most of the warnings/errors given at level one indicate problems with finding all header files, having al implicit macros set properly, and/or mimicking the compiler you use normally in a sufficiently precise way.
As always, I hesitate to advertise my own work, but if you want, take a look at my "How to wield PC Lint" PDF, where I have documented detailed instructions to handle the initial deployment of PC Lint and tackling the many warnings/errors/infos/notes you may be buried under.
When I started introducing PC-Lint to a new project I did the following:
As suggested by Johan Bezem, ran a -w1 level check over the whole thing. This doesn't actually find any new problems, but checks that your program is syntactically valid and finds any configuration issues. Nothing major, assuming your project compiles already.
Run the test again with -w2 level. This found 53,000 issues, which was a bit much to tackle in one go.
Pick a typical bad file, then suppress any errors that seem
irrelevant or non-urgent (eg. error 525: (Warning -- Negative indentation from line xxx)
adding -e525 to the command line or config file, until you find one that seems serious.
In my case this was
error 442: (Warning -- for clause irregularity: testing direction inconsistent with increment direction), i.e. a 'for' loop
that looked like it should be counting up was actually counting
down.
Reset the test level back to -w1 but added in the critical problem by number, -w1 +e442 in this case. Re-run it over the whole project then fix all the instances of that problem.
Back to stage 2 and try again.
This combination of fixing actual problems and suppressing likely false alarms soon gets your numbers under control.
So that everything gets better over time we also implement a script that does a thorough (full -w2 or -w3) check on any files that are created or modified.
I also found the tool LintProject very helpful as it can do an entire Visual Studio solution in one go, with tables with numbers of errors and worst offenders!
I am working on a rather large project, and I am having strange problems with the IDE in terms of error checking and somewhat with IntelliSense.
Usually if I were to type something boneheaded, like "int a = "aa";", it would underline "aa" in red. However I am seeing VS do this to random parts of my code when I make insignificant changes.
For example:
/*
Some comment here, just going to stretch it out for my example..
*/
int proto1();
int proto2();
If I make changes to other parts of the project, sometimes random functions will get underlined, and even part of a comment. Like just 30 minutes ago it underlined the equivalent of half of that comment beginning in the middle of the word "comment", also it underlined all of int proto1(); and part of int proto2();
I would post screenshots but I am bound by contract not to disclose any work, and I can't easily replicate it in smaller projects.
I don't understand why it does this. When I compile the project, any fake errors and underlining it did goes away and it compiles fine. The point though, is there are no errors. It's making up random errors and underlining random lines/words/half words. I would also like to note that there seems to be a large delay in loading new intellisense information, almost by 2-3 minutes or longer.
I'll try and reproduce it in an unrelated project and post here if I can. However, any help would be appreciated.
Thanks!
*Edit: Forgot to note that hitting the space key several times will on occasion correct the errors however this isn't reliable and does not always work.
Intellisense sometimes can really get stuck with complicated code. I guess until VS2012 release comes out, there's nothing we can do.
There's however one trick that I'm using if this happens - switch your build configuration Debug -> Release and then back again. You don't have to wait, you can just click two times on this drop-down box. It should refresh IS cache and make red error underlines dissappear.
Intellisense is often off, but make sure you have latest updates installed.
I just installed sp1 yesterday and lot of Intellisense issues went way.
I see this is a stale question but some may find this helpful.
I just had this same issue. I tried many of the solutions outlined here and elsewhere. I finally tried running Visual Studio as another user (Shift Right Click Run As Different User) and the issue did not present. I then logged into my computer as another user and deleted the profile of the user I was having the issue with.
If your profile is important to you or there is information within it that is important I highly recommend backing up relevant information first. If you don't understand what information you profile contains make sure you do prior to deleting it.
1) Log in as different user (with admin privileges) than you want to delete
2) Open Properties for Computer
3) Advanced system settings (on the left side)
4) Settings for User Profiles (in the middle)
5) Select the profile you want to delete and click the delete button
6) Reboot
Credit to:
https://superuser.com/questions/63017/how-do-i-delete-a-user-profile-on-a-windows-7-machine-that-is-part-of-a-domain
I had the same issue, and in my case it was mostly related to library functions and types defined in libraries. This one fixed it for me:
Open command line parameters. You can use following to reach there:
Project > ProjectName Properties > Configuration Properties > Linker > Command Line
In the Additional Options box at the bottom add
/I "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include"
You will of course need the correct path where Visual Studio is installed.
Bingo! I hope it works for you too. :)
I have a solution with 21 C++ projects and 1 VB.NET project.
The IDE responds very slowly when I simply move the carret in a file or try to open the menu. The process seems to take 50% of CPU for each movement.
It only happens with this solution and only on my machine.
The solution has total of 2380 source and header files, of which 1280 are header files.
I tried to remove all connection to the source control (Perforce) but it didn't help.
Also, I have Visual Assist installed but even after removing it (uninstall), the same behavior continued.
Any idea?
Deactivate intellisense.
Link
Intellisense parses the whole project and slows down the IDE drastically. If you use Visual Assist then you won't really need it. Visual Assist is less resource hungry and scans in the background, intellisense steals too many resources during its parsing.
Could this apply in your case?
http://coolthingoftheday.blogspot.com/2008/03/visual-basic-2008-hotfix-to-fix-slow.html
Note that disabling Intellisense may also break stuff like the Class Wizard (at least I'm pretty sure it does in VS2005). As already suggested it's a good idea to get rid of all the temporary files like .ncb regularly, because they can get huge and will slow down the IDE.
Also, if you're using Visual Assist, try rebuilding the database, disabling it or installing a different version.
I have a few solutions with over 100 projects, so I know exactly how you feel. Solutions containing some managed projects are especially bad. Disabling Intellisense helps a lot. I've never seen such problems from Visual Assist (or other similar refactoring tools), and that fills in a lot of the missing functionality from losing Intellisense.
I've also encountered some projects that had code that would cause the Intellisense thread to endlessly loop and never finish parsing the code. Most of those times we were never able to pin down the exact bit of code that caused the problem. Certain heavy use of templates and nested macros were often high on the suspicion list.
The only good way to be sure that Intellisense is disabled is to create a directory with the same name as the ncb file. Go to your solution directory, delete the ncb, and create a directory named your_solution_name.ncb. Because it can't recreate the ncb file, you'll get an error box to click through every time you open the solution, but that's a small price to pay.
Simply deleting the ncb will mean that VS will just create it again. The methods that I've seen from inside the VS options will turn off some of the features but will not prevent it from trying to parse all your code.